[Click] [Bug] patchless click misbehaving with recent Linux kernel vlan changes
Eddie Kohler
ekohler at gmail.com
Wed Jan 16 12:20:37 EST 2013
By the way:
On 1/15/13 3:35 PM, Giorgio Calarco wrote:
> simply stucks and sends nothing. What I found confusing is that
> at the ./configure stage, since pcap_inject is not found within
> the pcap library, it is substituted by a dummy method (which does
> nothing) and the compilation goes on as if everything was fine.
No. ToDevice calls pcap_sendpacket(), which I thought was the right
thing to do. If it's not I'd appreciate a patch.
Eddie
> This can be misleading, and some messages from the stdout
> would be helpful, since the problem can then be determined only
> by examining the (long) configure.log file.
>
> Moreover, I'm not sure if this is really a bug, maybe there's a new pcap
> method to call to xmit a packet now ?
>
> (The kernel development is becoming overwhelming, I think)
>
> My regards,
> Giorgio
>
>
> On Tue, Jan 15, 2013 at 8:56 PM, Eddie Kohler <ekohler at gmail.com
> <mailto:ekohler at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto:click at amsterdam.lcs.mit.edu>
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.mit.edu>
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>
More information about the click
mailing list