Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problem with 'vlan' expressions #113

guyharris opened this issue Apr 16, 2013 · 3 comments

problem with 'vlan' expressions #113

guyharris opened this issue Apr 16, 2013 · 3 comments


Copy link

Converted from SourceForge issue 2693245, submitted by linkj

When using the 'vlan' filter expressions I found the order in which the 'vlan' filter is placed matters. That is, 'vlan and icmp' will yield different results from 'icmp and vlan'. I have never seen this problem with any other combination of BPF filter expressions for tcpdump, only with the 'vlan' expression in combination with other expressions. See below for an example.

# tcpdump  -nn -t -r sample.pcap 'vlan and icmp'
reading from file sample.pcap, link-type EN10MB (Ethernet)
IP > ICMP echo request, id 53249, seq 33054, length 1477
IP > ICMP echo reply, id 53249, seq 33054, length 1477
IP > ICMP echo request, id 44866, seq 22307, length 1480
IP > ICMP echo reply, id 44866, seq 22307, length 1480

# tcpdump  -nn -t -r sample.pcap 'icmp and vlan'
reading from file sample.pcap, link-type EN10MB (Ethernet)
tcpdump: expression rejects all packets

I've seen this problem tcpdump v4.0.0 and earlier versions. I am not sure if this is a libpcap issue, keyboard to floor problem or something to do with how filter expressions are processed inside tcpdump.

Copy link
Member Author

Submitted by guy_harris

This behavior is documented in the tcpdump man page in tcpdump 3.9.x (and in the pcap-filter man page in libpcap 1.x):

         vlan [vlan_id]
                 True if the packet is an IEEE  802.1Q  VLAN  packet.   If
                 [vlan_id]  is  specified, only true if the packet has the
                 specified vlan_id.  **Note  that  the  first  vlan  keyword
                 encountered  in  expression  changes the decoding offsets
                 for the remainder of expression on  the  assumption  that
                 the  packet is a VLAN packet.  The vlan [vlan_id] expres-
                 sion may be used more than once, to filter on VLAN  hier-
                 archies.  Each use of that expression increments the fil-
                 ter offsets by 4.**

                 For example:
                      vlan 100 && vlan 200
                 filters on VLAN 200 encapsulated within VLAN 100, and
                      vlan && vlan 300 && ip
                 filters IPv4 protocols encapsulated in VLAN 300  encapsu-
                 lated within any higher order VLAN.

(Filter expressions are processed inside tcpdump by handing them to libpcap's pcap_compile() routine; tcpdump doesn't know anything about filtering, it leaves that to libpcap.)

And there is another filter operation that behaves this way - "mpls".

The problem is that filter expressions don't handle VLAN headers without an explicit "vlan" keyword - just "icmp", for example, won't find ICMP packets inside arbitrary numbers of VLAN headers. Given that the BPF "machine language" doesn't support looping (so you can't shove code into the kernel that can loop for an arbitrary amount of time), the general VLAN problem can't be solved with BPF as it exists.

At some point it might be nice to fix that, but at that point people would probably then ask to have filters also look inside GRE and PPPoE and... packets, and filtering starts getting even more complicated.

So, for now, the "vlan" expression will continue to behave this way.

Copy link

Also reviewed on the mailing list.

Copy link

For posterity, there is now a FAQ entry about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

No branches or pull requests

2 participants