Follow up. After digging into the click source I found that click is simply calling pcap_inject() on these packets. After tracing through the libpcap source it looks like this may be another bug in the Linux kernel. I've started a thread on linux-netdev relating to the issue.
http://marc.info/?l=linux-netdev&m=135760359019679&w=3 On Fri, Dec 21, 2012 at 2:07 PM, Paul Pearce <pea...@cs.berkeley.edu> wrote: > Hello folks, > > Summary: > Vlan tagged packets emitted by patchless click do not have the same > properties as other vlan tagged packets on the same interface as of > Linux 3.x. > > This is a bit long, so please indulge me. > > Background thread from the libpcap devs: > http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/msg06698.html > > Summary of the background thread: > * In April 2011 (net-dev commit > bcc6d47903612c3861201cc3a866fb604f26b8b2 ) the Linux kernel began > stripping vlan information from packet *HEADERS* (not from the raw > packets themselves) and inserting that information into the skb > metadata prior to it reaching the filters. > * As of today (12/21/2012) Berkeley Packet Filter (bpf) facilities > don't have the ability to access the vlan meta-data (although such a > patch is under review in net-next). > * Also as of today (12/21/2012) libpcap has no way to do kernel-level > filtering of packets based on vlan tags (this means capturing packets > based on vlan tags on live interfaces). Although they're working on > it. > > How does this impact click? > > Click packets are emitted with the vlan header information intact > rather than being stripped and added to the skb metadata. > > **This means vlan tagged packets on the same interface have a mix of > stripped and non-stripped headers. This causes a variety of problems > including difficulty filtering packets** > > This problem manifests itself when you try to use a "vlan" tcpdump > filter on a live interface. I realize tcpdump picking up the packets > or not is a libpcap problem, not a click problem. I'm just using this > to demonstrate that the click-emitted packets have different > properties. > > The rest of this email documents tests to demonstrate the problem > along with more info about the ramifications. > > ********** > > Sample click config (run from click git commit > 9200a743a27f4a0e8f40299e5f8d865e248282b1 Nov 9 2012): > ----------------------------------------------------- > InfiniteSource(PAYLOAD, LIMIT 1) > // This isn't a properly formatted ARP packet, but it doesn't > matter for this test. > -> EtherVLANEncap(0x0806, 1:1:1:1:1:1, 2:2:2:2:2:2, 99) > -> Queue > -> ToDevice(eth3); > ----------------------------------------------------- > > For the test I externally send a single real arp packet from another > machine to eth3 with a vlan tag of 5. I then turn on click so it emits > one vlan 99 tagged packet. > > Output of `tcpdump -i eth3 -e -n -XX`: > ------------------------------------------------------------- > > 13:28:02.011785 00:50:56:9c:4c:82 > Broadcast, ethertype 802.1Q > (0x8100), length 64: vlan 5, p 0, ethertype ARP, Request who-has > 10.3.0.3 tell 10.3.9.111, length 46 > 0x0000: ffff ffff ffff 0050 569c 4c82 8100 0005 .......PV.L..... > 0x0010: 0806 0001 0800 0604 0001 0050 569c 4c82 ...........PV.L. > 0x0020: 0a03 096f 0000 0000 0000 0a03 0003 0000 ...o............ > 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 13:28:03.710886 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype > 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP] > 0x0000: 0202 0202 0202 0101 0101 0101 8100 0063 ...............c > 0x0010: 0806 5041 594c 4f41 44 ..PAYLOAD > > ------------------------------------------------------------- > This is expected, we see the actual packet as well as the generated > packet from our infinite source since we aren't using any filters > > Output of tcpdump -i eth3 -e -n -XX "vlan": > ------------------------------------------------------------- > > 13:28:03.710882 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype > 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP] > 0x0000: 0202 0202 0202 0101 0101 0101 8100 0063 ...............c > 0x0010: 0806 5041 594c 4f41 44 ..PAYLOAD > > -------------------------------------------------------------- > > This is the problem. The correct behavior (believe it or not) is to > not see anything. > > If click conformed to the new Linux behavior of stripped headers and > skb meta data we'd not see anything since libpcap hasn't updated to > conform to the new standard. If click doesn't conform to the new Linux > behavior once libpcap and bpf's update these packets will be lost. > > At present because of the mix of stripped and non-stripped headers > when click is in use it's impossible to write a single packet filter > that will match both classes of packets. For example if I wanted to > filter arp packets, I'd need the filter "arp" for the real vlan tagged > packets, and the filter "vlan and arp" for the click emitted vlan > packets. > > If this behavior can't be avoided for some reason I think a big > documentation warning is necessary at the least. > > Ugh. What a mess. =( > > -Paul Pearce > > Security Graduate Student > Computer Science > University of California, Berkeley _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
