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

I must confess that when it comes to dumpcap I am just a dummy. Anyway, I am using CentOS 7 and I did use dumpcap as you suggested and what I have is:

dumpcap -v
Dumpcap 1.10.14 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.50.3, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), without libnl.

Running on Linux 3.10.0-862.3.2.el7.x86_64, with locale en_US.UTF-8, with
libpcap version 1.5.3, with libz 1.2.7.
      Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz

Built using gcc 4.8.5 20150623 (Red Hat 4.8.5-16).

On the "real" environment I did (the ...(more)

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

Your dumpcap version is quite old but your libpcap version is newer than mine. (My Linux machine is running RHEL6). I honestly don't understand what these lines mean either:

(000) ldb      [-4048]
(001) jeq      #0x1             jt 2    jf 7

I think there is very likely a bug with your version of libpcap. Can you try to upgrade? From http://www.tcpdump.org/libpcap-changes.txt, I see the following, which might be relevant:

Wednesday Nov. 12, 2014 [email protected]/[email protected]
  Summary for 1.7.0 libpcap release
    Fix handling of zones for BPF on Solaris
    new DLT for ZWAVE
    clarifications for read timeouts.
    Use BPF extensions in compiled filters, fixing VLAN filters
    some fixes to compilation without stdint.h
    EBUSY can now be returned by SNFv3 code.
    Fix the range checks in BPF loads
    Various DAG fixes.
    Various Linux fixes.

cmaynard ( 2018-07-05 18:20:48 +0000 )edit

Look: yum list installed | grep libcap compat-libcap1.x8664 1.10-7.el7 @anaconda/7.4
libcap.x8664 2.22-9.el7 @anaconda/7.4
libcap-ng.i686 0.7.5-4.el7 @rhel-7-workstation-rpms libcap-ng.x86_64 0.7.5-4.el7 @anaconda/7.4

So I guess the libcap on my system is quite above 1.7.0 you mention. BTW, your link send us to 1.8.0, not to 1.7.0. I guess the confusion is that I installed wireshark from epel and that was the way they compiled dumpcap, using a old libpcap. I will probably need to uninstall it, download all sources and compile it on the machine. This will take quite long as this system can not have Internet access... Anyway, any other suggestion?

moacir ( 2018-07-05 18:49:57 +0000 )edit

see more comments

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.

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

see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

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