On Mon, Dec 5, 2011 at 10:50 AM, Thomas De Schampheleire <[email protected]> wrote: > Hi, > > On Wed, Nov 30, 2011 at 10:06 AM, Thomas De Schampheleire > <[email protected]> wrote: >> On Wed, Nov 30, 2011 at 8:52 AM, Jiri Pirko <[email protected]> wrote: >>> Tue, Nov 29, 2011 at 09:35:00PM CET, [email protected] wrote: >>>>Le 29/11/2011 14:38, Thomas De Schampheleire a écrit : >>>>>Hi, >>>>> >>>>>I'm seeing incorrect tcpdump output in the following scenario: >>>>> >>>>>* ethernet bonding enabled in the kernel, and a single network >>>>>interface (eth0) added as slave >>>>>* bonding mode was set to broadcast, but I don't think this matters >>>>>* VLAN added to the bond0 network interface >>>>>* ip address set on the vlan interface (bond0.1234) >>>>>* tcpdump capturing full packets (-xx or even -x) on the eth0 interface >>>>> >>>>>Then, when pinging from another machine to this ip address, the ping >>>>>reply packets shown by tcpdump incorrectly have a double VLAN tag. >>>>>However, what really appears on the wire is correct: a single VLAN >>>>>tag. >>>> >>>>Copied netdev, because bonding and vlan developers are there. >>>> >>>>Jiri, don't you think this might be related to the work you have done >>>>to make non-hw-accel rx path similar to hw-accel? >>> >>> I do not think so. The changes you are reffering to are unrelated to tx >>> path (where this issue has most probably roots in) >>> >>>> >>>> Nicolas. >>>> >>>>> >>>>>Here is the output from tcpdump: >>>>># /tmp/tcpdump -i eth0 -xx >>> >>> What hw is this? >> >> This is on a Freescale P4080 DPA mac (fsl,p4080-fman-1g-mac). >> >>> >>>>>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >>>>>listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes >>>>>01:04:04.607880 IP 192.168.1.2> 192.168.1.1: ICMP echo request, id 26933, >>>>>seq 4 >>>>>16, length 64 >>>>> 0x0000: 0600 0000 0020 0600 0000 0020 8100 0ffe >>>>> 0x0010: 0800 4500 0054 0000 4000 4001 b755 c0a8 >>>>> 0x0020: 0102 c0a8 0101 0800 98d7 6935 01a0 e528 >>>>> 0x0030: 0f2a 0000 0000 0000 0000 0000 0000 0000 >>>>> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 >>>>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 >>>>> 0x0060: 0000 0000 0000 >>>>>01:04:04.607889 IP 192.168.1.1> 192.168.1.2: ICMP echo reply, id 26933, >>>>>seq 416 >>>>>, length 64 >>>>> 0x0000: 0600 0000 0020 0600 0000 0020 8100 0ffe >>>>> 0x0010: 8100 0ffe 0800 4500 0054 cc07 0000 4001<-------- >>>>>extra VLAN header at 0x10 >>>>> 0x0020: 2b4e c0a8 0101 c0a8 0102 0000 a0d7 6935 >>>>> 0x0030: 01a0 e528 0f2a 0000 0000 0000 0000 0000 >>>>> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 >>>>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 >>>>> 0x0060: 0000 0000 0000 0000 0000 >>>>> >>>>> >>>>>Initial debugging showed that the addition of the extra VLAN header >>>>>takes place in function pcap_read_linux_mmap() of libpcap, in the >>>>>following snippet: >>>>> >>>>>#ifdef HAVE_TPACKET2 >>>>> if (handle->md.tp_version == TPACKET_V2&& >>>>> h.h2->tp_vlan_tci&& >>>>> tp_snaplen>= 2 * ETH_ALEN) { >>>>> struct vlan_tag *tag; >>>>> >>>>> bp -= VLAN_TAG_LEN; >>>>> memmove(bp, bp + VLAN_TAG_LEN, 2 * ETH_ALEN); >>>>> >>>>> tag = (struct vlan_tag *)(bp + 2 * ETH_ALEN); >>>>> tag->vlan_tpid = htons(ETH_P_8021Q); >>>>> tag->vlan_tci = htons(h.h2->tp_vlan_tci); >>>>> >>>>> pcaphdr.caplen += VLAN_TAG_LEN; >>>>> pcaphdr.len += VLAN_TAG_LEN; >>>>> } >>>>>#endif >>> >>> I haven't look into this code yet, but where's the code which does the >>> first header inclusion? >> >> I would assume this is done by the VLAN layer. This is a ping reply >> originating from the icmp code, passing down to the vlan layer, then >> to the ethernet bonding layer, and then to the hardware. But before >> this is passed to hardware, libpcap captures the packet. >> >> I haven't debugged that part, though, so I can't give you a direct >> pointer to the code that does it. >> >>> >>> >>>>> >>>>>Upon entry of this code, the packet in bp already contains a VLAN header. >>>>> >>>>>It's unclear to me where the problem lies exactly. I suspect it has >>>>>something to do with the ethernet bonding layer indicating it has >>>>>hardware vlan tagging support, while it does already fill in the vlan >>>>>header, and libpcap being confused by this. >>>>> >>>>>As mentioned previously, the packets on the wire are correct, and this >>>>>is purely a capturing problem. >>>>> >> > > Does anyone have an idea on how this is supposed to work and why the > extra header gets inserted?
Bump. I would expect that this problem is independent on the hardware, and therefore should be reproducible by others as well, pretty easily. Thanks, Thomas - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
