Vlan filter

vlan
filter

asked 2018-07-05 08:13:02 +0000

moacir
1 ●1 ●2 ●1

updated 2018-07-05 15:47:15 +0000

JeffMorriss

6396 ●30 ●78

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 flag offensive close merge delete

Comments

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.

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

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

Jaap ( 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 :-)

NJL ( 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.

moacir ( 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)

cmaynard ( 2018-07-05 14:05:30 +0000 )edit

see more comments

answered 2018-07-05 19:43:28 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

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)'

edit flag offensive delete link

Comments

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)

moacir ( 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?

cmaynard ( 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.

cmaynard ( 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.

moacir ( 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.

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

Couldn't you just filter at the source (the mirror) or does the switch not have that capability?

NJL ( 2018-07-06 14:14:11 +0000 )edit

Cmaynard, I am sure I am capturing vlan traffic. Actually, the problem is capturing too much traffic. But I will do the suggested test to see what I get and try to learn from the output. So far what I have done is to exclude a single vlan (the one with video-recorders for over 800 cameras) and then, on the same filter, exclude the second vlan traffic but based on IP addresses. While the camera traffic comes from several vlans to the recorders vlan, the second one only goes to the control center, being easy to filter based on a dst/src 1.2.3.4/24 type filter. So I got what I need.

NJL, the problem with the mirror of a LAG is that all transported vlans will be mirrored, no way to exclude any of them unless you remove the vlan from the LAG. I could, however ...(more)

moacir ( 2018-07-06 14:37:45 +0000 )edit

You could replay the packets using something like tcpreplay?

An even easier solution might just be to use tcpdump, which uses the exact same capture filter syntax as tshark and dumpcap. For example:

tcpdump -r infile.pcap -w outfile.pcap '(ether[12:2] = 0x8100 or ether[12:2] = 0x9100) and not (ether[14:2]&0x0fff = 3003 or ether[14:2]&0x0fff = 3099)'

... or if you prefer to view the output instead of writing it to a new file, maybe something like:

tcpdump -r infile.pcap -w - '(ether[12:2] = 0x8100 or ether[12:2] = 0x9100) and not (ether[14:2]&0x0fff = 3003 or ether[14:2]&0x0fff = 3099)' | tshark -r -

If your input file is large, you can limit the number of packets read using tcpdump's -c count option.

Ref: https://osqa-ask.wireshark.org/questi...

cmaynard ( 2018-07-06 15:55:40 +0000 )edit

How about simply splitting the capture file into several smaller ones filtered on their vlan value?

NJL ( 2018-07-06 17:28:25 +0000 )edit

And BTW - what switch platform are you using to do the mirror?

NJL ( 2018-07-06 17:42:58 +0000 )edit

Launching few instances of tshark for the vlans I want looks a good idea, as wireshark will then synchronize them. The platform is Huawei S6720.

moacir ( 2018-07-06 17:49:47 +0000 )edit

I will then use tcpdump and look at the results, looking for the right filter for the version I have.

moacir ( 2018-07-06 17:51:31 +0000 )edit

add a comment

Vlan filter

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Vlan filter edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Vlan filter