Unusual Behavior with Stacked VLAN Tags and Capture Filter

Have you tried filtering on both VLAN ids at the same time? Something like "vlan 992 and vlan 811"? If I remember correctly this is required when filtering on QinQ traffic.

Capture filter "vlan 992 or vlan 811" will not collect anything.
Capture filter "vlan 810 or vlan 811" will only collect the first VLAN (810).

as @Guy Harris already mentioned the vlan capture filter 'primitive' does some magic behind the curtains, and thus it does not work as you might expect it, based on the behavior of other logical OR operations in capture filters.

See man page of pcap-filter:

vlan [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] expression may be used more than once, to filter on
VLAN hierarchies. Each use of that expression increments the filter
offsets by 4.

So, lets have a look at the BPF code for the following capture filter

tcpdump -ni eth0 -d ‘vlan 100’

(000) ldh      [12]        

(001) jeq      #0x8100          jt 2    jf 6
(002) ldh      [14]
(003) and      #0xfff
(004) jeq      #0x64            jt 5    jf 6
(005) ret      #65535
(006) ret      #0

(000): Load the location of the ethertype.
(001): Is it a VLAN tag (0x8100)?
(002-004): If true: load the value at position 14 (the VLAN tag) and compare it with 0x64 (100 decimal)

So far, so good.

Now lets check the BPF code of the following capture filter

tcpdump -ni eth0 -d 'vlan 100 or vlan 200'

(000) ldh      [12]
(001) jeq      #0x8100          jt 2    jf 5
(002) ldh      [14]
(003) and      #0xfff
(004) jeq      #0x64            jt 10   jf 5
(005) ldh      [16]          <<=== PROBLEM HERE !!!
(006) jeq      #0x8100          jt 7    jf 11
(007) ldh      [18]
(008) and      #0xfff
(009) jeq      #0xc8            jt 10   jf 11
(010) ret      #65535
(011) ret      #0

(000-004): same as before
(005): The whole problem occurs here. As the vlan primitive increases the decoding offset by 4 (see man page above - regardless of logical operator), the second vlan primitive will simply look at the wrong place for the ethertype. It should look at position 12 in the ethernet frame, but due to the decoding offset increase of 4, it looks at position 16, which is apparently wrong for a logical OR vlan operation (at least as one would assume/expect how it should work).

Due to this behavior (call is a bug or not), you cannot capture for several vlan tags in a single capture filter, combined with a logical OR operation. Furthermore, if you use a logical AND operation, you will only see double tagged or QinQ frames (as @Jasper) mentioned.

Solution: Run several instances of tcpdump, each with a single vlan capture filter and later merge the capture files with mergecap.

tcpdump -ni eth0 -w /tmp/vlan811.pcap ‘vlan 811’&
tcpdump -ni eth0 -w /tmp/vlan800.pcap ‘vlan 800’&
tcpdump -ni eth0 -w /tmp/vlan900.pcap ‘vlan 900’&
sleep 500
killall tcpdump
mergecap -w /tmp/vlan800+811+900.pcap /tmp/vlan800.pcap /tmp/vlan811.pcap /tmp/vlan900.pcap

+++ UPDATE +++

I have to correct myself. It is possible to capture multiple (outer) vlan tags in a single capture filter, by doing the vlan tag matching 'manually'.

tcpdump -ni eth0 'vlan and (ether[14:2]&0xfff=100 or ether[14:2]&0xfff=200)'

If you look at the BPF code, you'll see that it is essentially the same as 'vlan 100' combined with 'vlan 200', which is essentially the same as 'vlan 100 or vlan 200'.

(000) ldh      [12]
(001) jeq      #0x8100          jt 2    jf 7
(002) ldh      [14]
(003) and      #0xfff
(004) jeq      #0x64            jt 6    jf 5
(005) jeq      #0xc8            jt 6    jf 7
(006) ret      #65535
(007) ret      #0

(000): Load the location of the ethertype.
(001): Is it a VLAN tag (0x8100)?
(002): If true: load the value at position 14 (the vlan tag)
(004): compare the vlan tag with 0x64 (100 decimal)
(005): compare the vlan tag with 0xc8 (200 decimal)

Regards
Kurt