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

[Eddie Kohler]

Hi Paul,

It sounds like you are running at userlevel, and that you are using 
METHOD PCAP (which is the default in recent versions)? Do let us know if 
you discover more. You could also try METHOD LINUX, although this is 
slower than pcap I believe.

Eddie


On 1/7/13 8:51 PM, Paul Pearce wrote:
> 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 <pearce at 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 at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>