Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump

[Thomas De Schampheleire <patrickdepinguin () gmail com>]

Hi,

On Wed, Nov 30, 2011 at 10:06 AM, Thomas De Schampheleire
<patrickdepinguin () gmail com> wrote:
> On Wed, Nov 30, 2011 at 8:52 AM, Jiri Pirko <jpirko () redhat com> wrote:
> > Tue, Nov 29, 2011 at 09:35:00PM CET, nicolas.2p.debian () gmail com 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?

Thanks,
Thomas
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.