# Vlan filter

I am capturing traffic from a trunk mirror. This trunk has over 30 VLANs and I would like to exclude some of them so I used:

tshark -i ens4f0 -f 'vlan and not (ether[14:2]&0x0fff = 100 or ether[14:2]&0x0fff = 200)' -b filesize:1000000 -a files:10 -w /capture/trunk0.pcap


However, the filter does exactly the opposite of what I want as it is capturing only VLANs 100 and 200. If I use:

tshark -i ens4f0 -f 'vlan and (ether[14:2]&0x0fff != 100 or ether[14:2]&0x0fff != 200)' -b filesize:1000000 -a files:10 -w /capture/trunk0.pcap


it happens the same...

What am I missing? How can I exclude some VLANs to be captured?

edit retag close merge delete

NJL, what I am doing is exactly what is suggested on the post. If I understood correctly, you can not capture two VLANs using "and", so you must use the expression I am using above. But as I said, I am getting the VLANs filtered but with the opposite of what I need as it will only capture 100 and 200 and exclude what I want to capture.

( 2018-07-05 08:48:31 +0000 )edit

That last expression should be ..!= 100 and ether[...

( 2018-07-05 09:58:19 +0000 )edit

@moacir: yeah I realized that after reading the article in detail, hence I deleted my original post. Apologies for not realizing it before I posted :-)

( 2018-07-05 10:12:50 +0000 )edit

Jaap, I just tested your suggestion using 'vlan and (ether[14:2]&0x0fff != 100 and ether[14:2]&0x0fff != 200)', didn't work either. It capture exactly the opposite, meaning only VLAN 100 and VLAN 200.

( 2018-07-05 10:51:25 +0000 )edit

You can verify BPF filters using dumpcap's -d option. For example, on my Windows machine with WinPcap 4.1.3, I get:

dumpcap -f "vlan and not (ether[14:2]&0x0fff = 100 or ether[14:2]&0x0fff = 200)" -d
Capturing on 'Ethernet 2'
(000) ldh      [12]
(001) jeq      #0x8100          jt 2    jf 7
(002) ldh      [14]
(003) and      #0xfff
(004) jeq      #0x64            jt 7    jf 5
(005) jeq      #0xc8            jt 7    jf 6
(006) ret      #65535
(007) ret      #0


On my Linux machine with libpcap 1.4.0, I get a slightly different result for the same filter where either 0x8100 or 0x9100 is accepted as the TPID for an 802.1Q frame:

dumpcap -f 'vlan and not (ether[14:2]&0x0fff = 100 or ether[14:2]&0x0fff = 200)' -d
Capturing on 'eth0'
(000) ldh      [12]
(001) jeq      #0x8100          jt 3    jf 2
(002) jeq      #0x9100          jt 3    jf ...
(more)
( 2018-07-05 14:05:30 +0000 )edit

Sort by » oldest newest most voted

While your version of libpcap (1.5.3) seems to be buggy, I think the problem is with the vlan primitive and the mistake of not dealing with its affect on offsets. From the pcap-filter man page:

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] expression may be used more than once, to filter on VLAN hierarchies. Each use of that expression increments the filter 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 encapsulated within any higher order VLAN.


So I think you can resolve your problem and avoid having to update your version of libpcap if you rewrite your capture filter without using the vlan primitive. I have not verified this, but something like:

'(ether[12:2] = 0x8100 or ether[12:2] = 0x9100) and not (ether[14:2]&0x0fff = 3003 or ether[14:2]&0x0fff = 3099)'

more

That is really "crazy"... When I use dumpcap using your last suggestion I get:

dumpcap -i ens4f0 -f '(ether[12:2] = 0x8100 or ether[12:2] = 0x9100) and not (ether[14:2]&0x0fff = 3003 or ether[14:2]&0x0fff = 3099)' -d
Capturing on 'ens4f0'
(000) ldh      [12]
(001) jeq      #0x8100          jt 3    jf 2
(002) jeq      #0x9100          jt 3    jf 8
(003) ldh      [14]
(004) and      #0xfff
(005) jeq      #0xbbb           jt 8    jf 6
(006) jeq      #0xc1b           jt 8    jf 7
(007) ret      #262144
(008) ret      #0


As a "dummy" on the above output, I think it is what you would expect on your first example. However, when I use tshark, with the command below, I don't get a single package captured.

tshark -i ens4f0 -f '(ether[12:2] = 0x8100 or ether[12:2] = 0x9100) and not (ether[14:2]&0x0fff = 3003 or ether[14:2]&0x0fff = 3099)' -b ...
(more)
( 2018-07-05 20:00:30 +0000 )edit

Are you sure you have traffic on other vlans? Or is some traffic of interest not vlan-encapsulated, in which case, you'd have to modify your filter accordingly?

( 2018-07-05 20:09:25 +0000 )edit

By the way, if you want to learn more about BPF, you might want to start with the original paper titled, "The BSD Packet Filter: A New Architecture for User-level Packet Capture" by Steven McCanne and Van Jacobson. There are of course other resources as well, such as filter.txt and others I'm sure.

( 2018-07-05 20:23:29 +0000 )edit

I will stop bugging you for a day and go over the documentation you recommended and do some tests (RTFM). Just as info (as you are helping a lot!), the mirror port is mirroring a LAG that transports over 20 VLANs. The native VLAN of the mirror port has no traffic, meaning that all traffic is 802.1Q tagged. And yes, when I do a capture of "anything", I have a lot of other traffic over several VLANs. The problem is that few seconds of capture generates gigabytes of data. So I need to exclude all video related VLANs to get what I need. Thank you for your help! I will comeback after going through the docs and do some more tests to share "think-full" results.

( 2018-07-05 20:54:39 +0000 )edit

Maybe start with a very simple filter first, just to make sure you're capturing any vlan traffic? For example:

'(ether[12:2] = 0x8100 or ether[12:2] = 0x9100)'


If that doesn't work, maybe you need to check for 0x88a8 instead/too?

'(ether[12:2] = 0x8100 or ether[12:2] = 0x9100 or ether[12:2] = 0x88a8)'


Once you confirm you're capturing this traffic, then you can begin to filter out the unwanted VLAN ID's.

( 2018-07-06 14:04:27 +0000 )edit