# Revision history [back]

### vlan capture filter ineffective

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 the traffic. I can see the VLAN field in the packets when present or not, so I presume is not that the driver or the kernel is handling the VLAN packets special - after all, they are captured and I see them.

The capture filter is not dropping the VLAN tagged packets.