[Bug] patchless click misbehaving with recent Linux kernel vlan changes

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/[email protected]/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