vlan tagged packets and libpcap breakage

[Ani Sinha <ani () aristanetworks com>]

hello folks :

Before I go into describing the real problem, I'd like to give some
background information for the context. Please bear with me.

As you guys might be aware, the way the Linux kernel handles vlan
tagged packets have changed. Please see the following commit in
mainline Torvalds' tree :

commit bcc6d47903612c3861201cc3a866fb604f26b8b2
Author: Jiri Pirko <jpirko () redhat com>
Date:   Thu Apr 7 19:48:33 2011 +0000

    net: vlan: make non-hw-accel rx path similar to hw-accel

    Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
    enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
    vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.

    For non-rx-vlan-hw-accel however, tagged skb goes thru whole
    __netif_receive_skb, it's untagged in ptype_base hander and reinjected

    This incosistency is fixed by this patch. Vlan untagging happens early in
    __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
    see the skb like it was untagged by hw.

    Signed-off-by: Jiri Pirko <jpirko () redhat com>

    v1->v2:
        remove "inline" from vlan_core.c functions
    Signed-off-by: David S. Miller <davem () davemloft net>


As a result of this patch, with or without HW acceleration support in
the kernel driver, the vlan tag information is pulled out from the
packet and is inserted in the skb metadata. Thereafter, the vlan tag
information for a 802.1q packet can be obtained my applications
running in the user space by using the auxdata and cmsg structure.

More recently, two more patches were committed to net-next that enable
the kernel BPF filter to filter packets using their vlan tags :

http://www.spinics.net/lists/netdev/msg214758.html
http://www.spinics.net/lists/netdev/msg214759.html


Now to the real problem. The filter that is currently generated by
libpcap (gencode.c) uses offsets into the packet to obtain the vlan
tag for a packet and then compare it to the one provided by the user
in the filter expression (gen_vlan()). This will no longer work if the
tag has been pulled off from the packet itself. One has to use the
negative offsets (SKF_AD_VLAN_TAG) as used by the kernel BPF filter to
pass down the attribute that we need to compare against.  Now here's a
bigger problem. How do we avoid breakage in case we run libpcap on top
of an older kernel that does not extract the tags from the packet? How
do we handle cases of parsing and filtering against captured pcap
files that already have the vlan tags reinserted into the packet data?
There might be other corner cases that I am missing and not
understanding here.

Are you guys aware of the problem? Is there any thoughts as to how we
may be able to address the problem or not at all?

Thanks for the patience,
Ani
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers