| 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
| ||
|
Message-ID: <CAAXf6LVo1_L17-cnoJfX0uDyOsAu3Bi9E79vqj8eRNbHUXh9jg@mail.gmail.com>
Date: Fri, 16 Dec 2011 07:47:06 +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 Mon, Dec 5, 2011 at 10:50 AM, Thomas De Schampheleire
<patrickdepinguin@...il.com> wrote:
> Hi,
>
> On Wed, Nov 30, 2011 at 10:06 AM, Thomas De Schampheleire
> <patrickdepinguin@...il.com> wrote:
>> 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.
>>>>>
>>
>
> 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
--
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
Powered by blists - more mailing lists