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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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/[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 > > _______________________________________________ > > click mailing list > > [email protected] <mailto:[email protected]> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > click mailing list > [email protected] <mailto:[email protected]> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
