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?
>>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?
>>
>>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
>>
>>------------------------------------------------------------------------------
>>All the data continuously generated in your IT infrastructure
>>contains a definitive record of customers, application performance,
>>security threats, fraudulent activity, and more. Splunk takes this
>>data and makes sense of it. IT sense. And common sense.
>>http://p.sf.net/sfu/splunk-novd2d
>>_______________________________________________
>>Bonding-devel mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/bonding-devel
>>
>
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
