Multiple VLAN IDs and ranges with a single vlan option in capture filter

[dandreye]

Hello,

I've been redirected here with my capture filter related inquiry at Wireshark Ask: https://ask.wireshark.org/question/8487/tshark-capture-filter-using-vlan-id/

Would it be possible to extend vlan option syntax in a capture filter so that a single vlan option accepts >1 VLAN ID and ideally also VLAN ID ranges, e.g. something like "vlan 2001-2006,1506-1507, 1552-1553, 2025-2026"?

Many thanks in anticipation!

[mcr]

It would be possible, it requires code.

[guyharris]

It would probably be handled similarly to the way port is handled, so it might be something such as vlanrange 2001-2006 or 1506-1507 or 1552-1553 or 2025-2026.

[dandreye]

guyharris: such syntax consistent with portrange would be perfect (e.g. easier to remember from user perspective); perhaps any further similar requests for other options raised by others can also follow the same pattern.

[dandreye]

Really sorry for being annoying but is there a chance to see it implemented anytime soon? We're currently having to deal with gigabyte long packet captures for mere minutes of capturing...

[syn-bit]

Really sorry for being annoying but is there a chance to see it implemented anytime soon? We're currently having to deal with gigabyte long packet captures for mere minutes of capturing...

As a workaround you can use:

vlan and (ether[14:2]&0x0fff=2001 or ether[14:2]&0x0fff=2002 or ... or ether[14:2]&0x0fff=2026)

Of course with a whole list of vlans to capture this filter can be quite long, but at least, you get to have small capture files. Another option would be to filter out those vlans that carry the most traffic (if there are a couple of really chatty vlans).

[dandreye]

Thanks for your reply. Unfortunately it no longer works:

"The kernel no longer passes vlan tag information as-is to libpcap, instead BPF needs to access ancillary data." https://bugs.launchpad.net/ubuntu/+source/tcpdump/+bug/1641429

Please find my thread @ Wireshark Ask preceding my libpcap enhancement request: https://ask.wireshark.org/question/8487/tshark-capture-filter-using-vlan-id/

[syn-bit]

In that case, I just tried to use negative offsets (thanks for the link, I learned something new):

sake@x201:~$ sudo tcpdump -d -i enp0s25 vlan 100
[sudo] password for sake: 
(000) ldb      [-4048]
(001) jeq      #0x1             jt 2	jf 5
(002) ldb      [-4052]
(003) jeq      #0x64            jt 4	jf 5
(004) ret      #262144
(005) ret      #0
sake@x201:~$ sudo tcpdump -d -i enp0s25 vlan and ether[-4052:2]=100
(000) ldb      [-4048]
(001) jeq      #0x1             jt 2	jf 5
(002) ldh      [-4052]
(003) jeq      #0x64            jt 4	jf 5
(004) ret      #262144
(005) ret      #0
sake@x201:~$ sudo tcpdump -d -i enp0s25 "vlan and (ether[-4052:2]=100 or ether[-4052:2]=200)"
(000) ldb      [-4048]
(001) jeq      #0x1             jt 2	jf 6
(002) ldh      [-4052]
(003) jeq      #0x64            jt 5	jf 4
(004) jeq      #0xc8            jt 5	jf 6
(005) ret      #262144
(006) ret      #0
sake@x201:~$

Which seems to result in valid BPF code that is similar to code for the the "vlan 100" filter. I have not tried it myself (no vlan tagged interface available for testing at the moment), but I expect it to work.

And yes, we met on ask.wireshark.org too, I showed you the "vlan.id in {x..y a..b}" syntax :-)

[dandreye]

Thank you: I'll then give these negative offsets a try and report on the outcome.

Btw thanks for sharing the "vlan.id in {x..y a..b}" back then: the life with it got much better )

[fenner]

I recommend using ether[-4052]=100 - note that the code that libpcap uses ldb and your examples use ldh. The negative offset is simply a flag, I suspect that any load would work, but if you want to match what libpcap does, use the single byte mechanism.

There are a number of attributes accessible via the negative mechanism. I usually look in the kernel source/headers, /usr/include/linux/filter.h or net/core/filter.c .

Note that on a Linux SLL or SLL2 socket (i.e., "-i any"), negative offsets will be corrupted until my pull request or something similar is implemented: https://github.com/the-tcpdump-group/libpcap/pull/820

[syn-bit]

I recommend using ether[-4052]=100 - note that the code that libpcap uses ldb and your examples use ldh. The negative offset is simply a flag, I suspect that any load would work, but if you want to match what libpcap does, use the single byte mechanism.

Good point, missed that in my quick test :-)

[dandreye]

@syn-bit : really sorry for not getting back with the results back then. Soon after someone found a way to filter those VLANs in traffic before sending it to my VM, making these filters no longer necessary. I've just come across my old threads about it by chance and tried your negative offsets. They seem to work perfectly well with at least 2 of my VLANs, so I'll be using them for now whenever I have to filter it myself again: thank you! Meanwhile it'd be nice to see something like "vlanrange 2001-2006 or 1506-1507 or 1552-1553 or 2025-2026" implemented one day as per @guyharris 's reply above.

@fenner : could you please explain what ":?" I get when omitting ":2" as you advised? I thought ":2" means analyse 2 bytes starting at that offset, and as both of these seem to work equally well for my VLAN IDs >255 do I get it right that omitting ":2" makes it fall back to ":4" by default?

root@client:/tmp# tcpdump -d -i ens5 "vlan and (ether[-4052:2]=653 or ether[-4052:2]=654)"
(000) ldb      [-4048]
(001) jeq      #0x1             jt 2    jf 6
(002) ldh      [-4052]
(003) jeq      #0x28d           jt 5    jf 4
(004) jeq      #0x28e           jt 5    jf 6
(005) ret      #262144
(006) ret      #0
root@client:/tmp# 
root@client:/tmp# tcpdump -d -i ens5 "vlan and (ether[-4052]=653 or ether[-4052]=654)"
(000) ldb      [-4048]
(001) jeq      #0x1             jt 2    jf 6
(002) ldb      [-4052]
(003) jeq      #0x28d           jt 5    jf 4
(004) jeq      #0x28e           jt 5    jf 6
(005) ret      #262144
(006) ret      #0
root@client:/tmp#

[infrastation]

See also #158.