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.

Also reviewed on the mailing list.

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