Ask Your Question
0

vlan capture filter ineffective

asked 2018-12-07 19:45:19 +0000

Remarkable gravatar image

The following capture filters don't do what I expect:

  1. not (ether[12:2] = 0x8100 )
  2. not vlan
  3. vlan 1
  4. !ether proto 0x8100

The compiled code looks correct - for example, for the last one, 4)

 (000) ldh      [12]
 (001) jeq      #0x8100          jt 2   jf 3 
 (002) ret      #0 
 (003) ret      #262144

The behaviour is either all packets are captured, regardless of VLAN state, or none. Other capture filters work as expected - eg

  1. not udp
  2. arp

Both of those capture both instances of the packets on the wire - both with and without the VLAN tag. So the capture filter compiled code may be being usurped by another layer where VLAN presence is taken into account and the filter is adjusted to catch both VLAN and native packets. Very clever, and apparently there is a bug in the logic if the very bytes being scrutinized are the VLAN bytes.

The confounding thing is the capture filter not dropping the VLAN tagged packets.

Below are the specific details of my setup (irrelevant to the above issue, but included for completeness)

I have a Netgear switch with a mirrored port which I plug into a dedicated Broadcom NIC on my Linux box. Only Wireshark (v2.6.4 on Ubunutu 14.04.1, libpcap v 1.5.3) uses this port to sniff traffic from devices under development (video cameras utilizing Ethernet transports). The Netgear switch has a non-trivial configuration and essentially supports 3 segmented networks on groups of dedicated ports, using VLANS to keep traffic segregated. Inside the switch I do not any routing or other fancy manipulations - it is essentially 3 separate 8 port wirespeed switches. EXCEPT - the mirror port, which gets a copy of every packet going through the switch. (And I can alter it so only one port is monitored, or one virtual 8 port switch, or any combination - but for now, it is every packet is mirrored.) On the mirror port, I do see all traffic, and I am seeing two copies of each packet, one untagged, and the other tagged with VLAN.id=1. Otherwise the same packet. I assume the VLAN packet is an artifact of the switch itself needing to be on at least one VLAN, so it is understandable that the mirrored port is echoing those out.

BUT - I don't need to look at the VLAN packets; I don't need to capture them, even. If they are present, they are a duplicate of another packet in the capture. AND, they don't go out on any of the segments with the monitored devices on them. So essentially they are noise in the data, and consume space in captures, and don't impact the systems under test.

So, I have set up a capture filter on the incoming Ethernet port, per directions here and elsewhere. I have examined the compiled filter code, and it is accurate and should work, but doesn't. I have set up equivalent display filters and these work, essentially hiding 50% of ... (more)

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2018-12-07 20:49:47 +0000

Guy Harris gravatar image

Ubunutu 14.04.1, libpcap v 1.5.3

Linux has a long history of "helpfully" removing VLAN tags from packets supplied to the capture mechanism used by libpcap (PF_PACKET sockets).

libpcap has had to work around this "help" in a number of places. Dating back to libpcap 1.0.0, it's reconstructed the original packet by using VLAN tag information provided by the kernel; however, that doesn't handle packet filtering, which is done in the kernel after the VLAN tags were removed and before the packet is handed up to libpcap.

There are several closed-by-pulling-them-into-libpcap pull requests to fix the handling of VLAN tags in kernel filtering in Linux (issue #362 in that list is the only one that isn't related to that, although #686, #704, and #708 are code cleanups of the fixes rather than being fixes themselves, and some are earlier fix attempts abandoned in favor of later fixes). #391 was the first of the fixes; it first appeared in libpcap 1.7.2.

So you're going to need a bigger boat^W^W^W newer version of libpcap; 1.5.3 can't handle filtering of VLAN packets on Linux in live captures.

edit flag offensive delete link more

Comments

Thanks for the insightful response. So, if linux is in fact obfuscating the VLAN source of the incoming stream, and libpcap is aware and attempting to undo the meddling, and more recent versions of the library do that better, how do I entice Wirseshark to use more up to date libpcap libraries? I did a cursory search for doing that but found no clear answers.

Remarkable gravatar imageRemarkable ( 2018-12-10 18:11:10 +0000 )edit

Your Answer

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

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-12-07 19:45:19 +0000

Seen: 38 times

Last updated: Dec 07