Re: [tcpdump-workers] vlan tagged packets and libpcap breakage

[Ani Sinha <ani@aristanetworks.com>]

cc'ing netdev.


On Wed, Oct 31, 2012 at 2:01 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> Thanks for this email.
>
>>>>>> "Ani" == Ani Sinha <ani@aristanetworks.com> writes:
>     Ani> remove "inline" from vlan_core.c functions
>     Ani> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>     Ani> As a result of this patch, with or without HW acceleration support in
>     Ani> the kernel driver, the vlan tag information is pulled out from the
>     Ani> packet and is inserted in the skb metadata. Thereafter, the vlan tag
>     Ani> information for a 802.1q packet can be obtained my applications
>     Ani> running in the user space by using the auxdata and cmsg
>     Ani> structure.
>
> Do you think that the existance of this behaviour could be exposed in
> sysctl, /proc/net or /sys equivalent (we still don't have /sys/net...)?
> As a read only file that had a 0/1 in it?

yes, we definitely need a run time check. Whether this could be in the
form of a socket option or a /proc entry I don't know.

>
> Should be one stanza to net/dev/sysctl_net_core, I think.
> If we are fast, maybe no kernel will ship without it.
>
> (An aside, is this auxdata/cmsg info available on UDP sockets too?)
>
>     Ani> More recently, two more patches were committed to net-next that enable
>     Ani> the kernel BPF filter to filter packets using their vlan tags :
>
>     Ani> http://www.spinics.net/lists/netdev/msg214758.html
>     Ani> http://www.spinics.net/lists/netdev/msg214759.html
>
> okay...
>
>     Ani> Now to the real problem. The filter that is currently generated by
>     Ani> libpcap (gencode.c) uses offsets into the packet to obtain the vlan
>     Ani> tag for a packet and then compare it to the one provided by the user
>     Ani> in the filter expression (gen_vlan()). This will no longer work if the
>     Ani> tag has been pulled off from the packet itself. One has to use the
>     Ani> negative offsets (SKF_AD_VLAN_TAG) as used by the kernel BPF filter to
>     Ani> pass down the attribute that we need to compare against.  Now here's a
>     Ani> bigger problem. How do we avoid breakage in case we run libpcap on top
>     Ani> of an older kernel that does not extract the tags from the packet? How
>     Ani> do we handle cases of parsing and filtering against captured pcap
>     Ani> files that already have the vlan tags reinserted into the packet data?
>     Ani> There might be other corner cases that I am missing and not
>     Ani> understanding here.
>
> AFAIK, We will have to modify pcap-linux to produce different filters.
>
>     Ani> Are you guys aware of the problem? Is there any thoughts as to how we
>     Ani> may be able to address the problem or not at all?
>
> Nobody gave us a heads up, no.

Glad that I brought this up. Actually Bill Fenner who also works for
us helped me a lot in understanding the problem and potentially how it
can be addressed.


>
> It sounds like it's impossible to capture all traffic now, and do vlan
> filtering later on?

pcap files that already have the tags reinsrted should work with
current filter code. However for live traffic, one has to get the tags
from CMSG() and then reinsert it back to the packet for the current
filter to work. This is slow.

ani