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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAXf6LXDYmjaQK6g0q6vZLeDCH1yb5MT03c21Ehqv6TgUB_R3w@mail.gmail.com>
Date:	Wed, 30 Nov 2011 10:06:47 +0100
From:	Thomas De Schampheleire <patrickdepinguin@...il.com>
To:	Jiri Pirko <jpirko@...hat.com>
Cc:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>, bonding-devel@...ts.sourceforge.net,
	tcpdump-workers@...ts.tcpdump.org,
	Ronny Meeus <ronny.meeus@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump

On Wed, Nov 30, 2011 at 8:52 AM, Jiri Pirko <jpirko@...hat.com> wrote:
> Tue, Nov 29, 2011 at 09:35:00PM CET, nicolas.2p.debian@...il.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.
>>>


Best regards,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html