tcpdump's capture filter: "vlan" doesn't match

[Lukas Tribus]

Hi,



since 2.6.39 (including -rc1), tcpdump "vlan" capture filters don't mat=
ch
anymore. All 2.6.38 and older kernels are fine.


I reproduced this specifically on a r8169 NIC on 2.6.39-rc1, but I foun=
d
this problem initially on bnx2 and e1000e nics.


Howto reproduce: just tcpdump with a "not vlan", "vlan" or "vlan <vlani=
d>"
capture filter on a passive eth interface (dot1q/vlan/ip config not nec=
essary).

Actual behavior is that a "vlan [vlanid]" capture filter doesn't match =
the
(tagged) packet, and a "not vlan" capture filter matches everything.


Disabling rx-vlan-offloading via
ethtool -K eth0 rxvlan off

doesn't change anything.


Here we are filtering for "not vlan" and we can see that the matched fr=
ame
is vlan tagged:

# tcpdump -Uenc1 not vlan
tcpdump: verbose output suppressed, use -v or -vv for full protocol dec=
ode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 byte=
s
22:03:39.077584 70:ca:9b:01:23:34> 00:18:f8:01:23:34, \
*ethertype 802.1Q (0x8100), length 70: vlan 7, p 0*, ethertype IPv4, \
192.168.47.9.443> 192.168.32.30.39436: Flags [.], ack 255248912, \
[...]
1 packet captured
169 packets received by filter
0 packets dropped by kernel
59 packets dropped by interface
#




As suggested here [1], we can pipe everything through another tcpdump
instance:
tcpdump -Uw - | tcpdump -en -r - vlan <vlanid>


But that is not something that works for my specific use-case (dedicate=
d
sniffer box, dedicated interface connected to a Cisco SPAN/mirror port,
un/single/double-tagged packets, remotely accessible via remote-pcap [2=
]).


The sniffer should also be able to:
- maintain the frame as-is, including dot1q, dot1p (preferably
=A0 without artificial recreation of header fields/values and including=
CFI/DEI)
- "direct" capture filter based on vlan (not through multiple userspace
=A0 instances)

Kernel <=3D 2.6.38 perfectly satisfies those requirements.


Isn't disabling rx-vlan-offloading supposed to remedy those problems?




Thanks,

Lukas




[1] https://bugzilla.redhat.com/show_bug.cgi?id=3D498981
[2] https://github.com/frgtn/rpcapd-linux

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Borkmann]

Hi,
since 2.6.39 (including -rc1), tcpdump "vlan" capture filters don't match
anymore. All 2.6.38 and older kernels are fine.
I reproduced this specifically on a r8169 NIC on 2.6.39-rc1, but I found
this problem initially on bnx2 and e1000e nics.
Howto reproduce: just tcpdump with a "not vlan", "vlan" or "vlan <vlanid>"
capture filter on a passive eth interface (dot1q/vlan/ip config not necessary).
Actual behavior is that a "vlan [vlanid]" capture filter doesn't match the
(tagged) packet, and a "not vlan" capture filter matches everything.
Disabling rx-vlan-offloading via
ethtool -K eth0 rxvlan off
doesn't change anything.
Here we are filtering for "not vlan" and we can see that the matched frame
# tcpdump -Uenc1 not vlan
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:03:39.077584 70:ca:9b:01:23:34> 00:18:f8:01:23:34, \
*ethertype 802.1Q (0x8100), length 70: vlan 7, p 0*, ethertype IPv4, \
192.168.47.9.443> 192.168.32.30.39436: Flags [.], ack 255248912, \
[...]
1 packet captured
169 packets received by filter
0 packets dropped by kernel
59 packets dropped by interface
#
As suggested here [1], we can pipe everything through another tcpdump
tcpdump -Uw - | tcpdump -en -r - vlan <vlanid>
But that is not something that works for my specific use-case (dedicated
sniffer box, dedicated interface connected to a Cisco SPAN/mirror port,
un/single/double-tagged packets, remotely accessible via remote-pcap [2]).
- maintain the frame as-is, including dot1q, dot1p (preferably
without artificial recreation of header fields/values and including CFI/DEI)
- "direct" capture filter based on vlan (not through multiple userspace
instances)
Kernel <= 2.6.38 perfectly satisfies those requirements.
Isn't disabling rx-vlan-offloading supposed to remedy those problems?

There were some discussions on this in the past e.g. [1]. We have
SKF_AD_VLAN_TAG and SKF_AD_VLAN_TAG_PRESENT for the BPF filter on
this, but libpcap is currently not making use of any of them.

[1] http://thread.gmane.org/gmane.linux.network/247947

Thanks,
Lukas
[1] https://bugzilla.redhat.com/show_bug.cgi?id=498981
[2] https://github.com/frgtn/rpcapd-linux
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Lukas Tribus]

Post by Daniel Borkmann

Post by Lukas Tribus
Isn't disabling rx-vlan-offloading supposed to remedy those problems?

There were some discussions on this in the past e.g. [1]. We have
SKF_AD_VLAN_TAG and SKF_AD_VLAN_TAG_PRESENT for the BPF filter on
this, but libpcap is currently not making use of any of them.
[1] http://thread.gmane.org/gmane.linux.network/247947

Thanks for the link. I see the situation is unfortunate and although those
new BPF filters in the kernel may fix the actual filtering problem, one
thing seems to remain impossible: disabling all this kernel magic and
passing the frame as-is to libpcap without interception (avoiding any
kind of artificial header reconstruction).

How is the situation with netsniff-ng anyway? Does it use vlan BPF filter
in the kernel?



Regards,

Lukas

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Ani Sinha]

+fenner.

I had spent some considerable time in the past looking into this and
proposing a patch :

http://seclists.org/tcpdump/2013/q1/0

However, there was no feedback and I got sucked into a different
project and this work fell through the cracks. If someone else picks
it up, I will be glad to help/lend a hand.

Cheers,
ani

Post by Lukas Tribus

Post by Daniel Borkmann

Post by Lukas Tribus
Isn't disabling rx-vlan-offloading supposed to remedy those problems?

There were some discussions on this in the past e.g. [1]. We have
SKF_AD_VLAN_TAG and SKF_AD_VLAN_TAG_PRESENT for the BPF filter on
this, but libpcap is currently not making use of any of them.
[1] http://thread.gmane.org/gmane.linux.network/247947

Thanks for the link. I see the situation is unfortunate and although those
new BPF filters in the kernel may fix the actual filtering problem, one
thing seems to remain impossible: disabling all this kernel magic and
passing the frame as-is to libpcap without interception (avoiding any
kind of artificial header reconstruction).
How is the situation with netsniff-ng anyway? Does it use vlan BPF filter
in the kernel?
Regards,
Lukas

[Daniel Borkmann]

Post by Lukas Tribus

Post by Daniel Borkmann

Post by Lukas Tribus
Isn't disabling rx-vlan-offloading supposed to remedy those problems?

There were some discussions on this in the past e.g. [1]. We have
SKF_AD_VLAN_TAG and SKF_AD_VLAN_TAG_PRESENT for the BPF filter on
this, but libpcap is currently not making use of any of them.
[1] http://thread.gmane.org/gmane.linux.network/247947

Thanks for the link. I see the situation is unfortunate and although those
new BPF filters in the kernel may fix the actual filtering problem, one
thing seems to remain impossible: disabling all this kernel magic and
passing the frame as-is to libpcap without interception (avoiding any
kind of artificial header reconstruction).
How is the situation with netsniff-ng anyway? Does it use vlan BPF filter
in the kernel?

So in netsniff-ng we don't do obscure header reconstruction as it
hurts performance and it can result in incorrect reconstruction cases.

You however can define a bpf_asm program (e.g. tools/net/ in kernel
tree) and use instruction overloading for the vlan case from there.
Thus, you're not tied to the libpcap compiler which misses this.

For more details, I refer you to Documentation/networking/filter.txt .