Ask Your Question
0

List of valid "ip proto" by name for capture filter expression

asked 2026-05-07 04:42:09 +0000

cuuld gravatar image

Hi,

We have a custom in-house pcap tool that has a mapping of protocol (numeric) values to names, and the internal tool supports specifying the protocols by name in capture filter expression, so one can do that instead of providing the protocol number in hex or decimal for the capture filter expression.

I tried same on tcpdump and wireshark but among the names, the only filter expression that works there is "ip proto l2tp", I didn't check that actual captured packets are matching that as I don't have the setup to generate that traffic either, but the tool didn't fail complaining about invalid filter.

The name mapping of the in-house tool has

for ethertype protocols:

  • ip
  • ip4
  • ip6
  • arp
  • lldp
  • slow
  • pae

and for ip protocols:

  • icmp
  • igmp
  • tcp
  • udp
  • esp
  • ah
  • icmp6
  • vrrp
  • l2tp

So I'm just curious is l2tp the only one that will work for tcpdump and wireshark, or are there other names (even ones the in-house tool hasn't mapped) that work that I'm just not aware of?

Or is tcpdump and wireshark acceptance of the l2tp string value a bug instead?

edit retag flag offensive close merge delete

Comments

I tried same on tcpdump and wireshark but among the names, the only filter expression that works there is "ip proto l2tp",

How are you specifying the filter to Wireshark? Are you mixing capture and display filters?

Wireshark dfref - l2tp is valid in a Wireshark display filter.
Wireshark man pages -> pcap-filter
l2tp is not in the list of valid protocols for a capture filter.

C:\>wireshark -f ip proto l2tp

wireshark: Invalid argument: l2tp

Usage: wireshark [options] ... [ <infile> ]
Chuckc gravatar imageChuckc ( 2026-05-07 13:49:17 +0000 )edit
Chuckc gravatar imageChuckc ( 2026-05-07 13:56:07 +0000 )edit

I actually tested using tshark:

tshark -i en0 -f "ip proto l2tp"

but I just tried with wireshark as you shown and it works for me.

Maybe a difference between macOS vs Windows or a difference in Wireshark version. Because I see your example shows Windows. I'm using macOS, and running Wireshark 4.4.6.

Also, in the related question/post, I see the OP commented also using "ip proto l2tp" in one of the comments.

cuuld gravatar imagecuuld ( 2026-05-08 06:59:27 +0000 )edit

Thanks for the learning exercise. :-) npcap does not support name resolution.
Depending on their answer, Wireshark needs to handle this better until/if npcap supports it.
844: pcap_compile() support for name files - ethers, hosts, protocols, services, other?

Chuckc gravatar imageChuckc ( 2026-05-08 12:38:52 +0000 )edit

The original question: "List of valid "ip proto" by name ..."
On macOS that would be /etc/protocols. For Windows see discussion on the npcap issue #844.

Chuckc gravatar imageChuckc ( 2026-05-09 19:39:09 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2026-05-07 22:06:43 +0000

SYN-bit gravatar image

updated 2026-05-11 14:53:14 +0000

cmaynard gravatar image

I tried some of the protocols in your list with both the form <protocol-name and ip proto <protocol-name>. It seems that they are mutually exclusive. Looking at the BPF manpage, it turns out you need to escape the protocol names that also exist as a proto qualifier with a backslash:

ip proto protocol

True if the packet is an IPv4 packet of protocol type protocol. For this primitive it does not matter whether the IPv4 packet is fragmented or not. Protocol can be a number or one of the names recognized by getprotobyname(3), for example: ah, esp, eigrp (only in Linux with glibc, FreeBSD, NetBSD, DragonFly BSD, macOS, and QNX), icmp, igmp, igrp (only in Haiku and OpenBSD), pim, sctp, tcp, udp or vrrp. Note that most of these example identifiers are also keywords and must be escaped via backslash (\). Note that this primitive does not chase the protocol header chain.

So ip proto \icmp does indeed work. As does ip proto \l2tp.

When doing this in a terminal window on the CLI, the shell might also eat up the \, so you might need to escape the \ with a \ resulting in ip proto \\icmp or use single quotes (ip proto '\l2tp')to prevent the escaping by the shell.

edit flag offensive delete link more

Comments

Thanks, that is insightful info. Strangely, l2tp works without escaping, or at least no error is thrown. The other protocols do need the escaping. Of course, l2tp also works with the escaping as well.

cuuld gravatar imagecuuld ( 2026-05-08 07:45:04 +0000 )edit

Thanks @SYN-bit I read just far enough into the man page to find what I wanted to see instead of the actual syntax answer. Oops.

Chuckc gravatar imageChuckc ( 2026-05-08 12:36:42 +0000 )edit
0

answered 2026-05-12 23:03:12 +0000

Guy Harris gravatar image

updated 2026-05-12 23:03:55 +0000

This is a general libpcap issue, rather than a Wireshark-specific issue.

The libpcap filter language, which is documented in the pcap-filter man page, supports ip filter vrrp, for example, but doesn't support ip filter l2tp, as the lexical analyzer in libpcap treats vrrp as a protocol filter by itself, i.e., you can say just vrrp as a filter expression, but doesn't treat l2tp as a protocol filter by itself, so you can't say just l2tp as a filter expression.

Names that can be used as filters by themselves have to be "escaped" with a leading backslash when used as a protocol name for ip proto, but names that can't be used as filters by themselves don't have to be escaped.

Thus:

  • vrrp is a filter by itself;
  • ip filter vrrp is not legal, but ip filter \vrrp is;
  • l2tp is not a filter by itself;
  • ip filter l2tp is legal, as is ip filter \l2tp.

There is no underlying reason for this, but one problem with making l2tp by itself a filter is that it'd make ip filter l2tp not a valid filter, so it might break backwards compatibility.

It might be that the filter grammar could be changed to allow ip filter vrrp to be valid, if that doesn't make the correct parsing of that filter ambiguous. That would complicate the grammar but simplify the user experience, which I, at least, would consider to be a worthwhile tradeoff.

Please file an enhancement request for this on the libpcap issues list. (That will require a GitHub account.)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2026-05-07 04:42:09 +0000

Seen: 168 times

Last updated: May 12