* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
[not found] <CAAXf6LXiONe5Kb8tdQbQs3SWg8cc6SK_md7-vOV8qN4vYmL8qw@mail.gmail.com>
@ 2011-11-29 20:35 ` Nicolas de Pesloüan
2011-11-30 7:52 ` Jiri Pirko
0 siblings, 1 reply; 5+ messages in thread
From: Nicolas de Pesloüan @ 2011-11-29 20:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas De Schampheleire, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev
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?
Nicolas.
>
> Here is the output from tcpdump:
> # /tmp/tcpdump -i eth0 -xx
> 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
>
> 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
> Bonding-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bonding-devel
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
2011-11-29 20:35 ` [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump Nicolas de Pesloüan
@ 2011-11-30 7:52 ` Jiri Pirko
2011-11-30 9:06 ` Thomas De Schampheleire
0 siblings, 1 reply; 5+ messages in thread
From: Jiri Pirko @ 2011-11-30 7:52 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Thomas De Schampheleire, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev
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?
>>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
>>Bonding-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/bonding-devel
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
2011-11-30 7:52 ` Jiri Pirko
@ 2011-11-30 9:06 ` Thomas De Schampheleire
2011-12-05 9:50 ` Thomas De Schampheleire
0 siblings, 1 reply; 5+ messages in thread
From: Thomas De Schampheleire @ 2011-11-30 9:06 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev
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.
>>>
Best regards,
Thomas
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
2011-11-30 9:06 ` Thomas De Schampheleire
@ 2011-12-05 9:50 ` Thomas De Schampheleire
2011-12-16 6:47 ` Thomas De Schampheleire
0 siblings, 1 reply; 5+ messages in thread
From: Thomas De Schampheleire @ 2011-12-05 9:50 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
2011-12-05 9:50 ` Thomas De Schampheleire
@ 2011-12-16 6:47 ` Thomas De Schampheleire
0 siblings, 0 replies; 5+ messages in thread
From: Thomas De Schampheleire @ 2011-12-16 6:47 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev
On Mon, Dec 5, 2011 at 10:50 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> 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?
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-12-16 6:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAAXf6LXiONe5Kb8tdQbQs3SWg8cc6SK_md7-vOV8qN4vYmL8qw@mail.gmail.com>
2011-11-29 20:35 ` [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump Nicolas de Pesloüan
2011-11-30 7:52 ` Jiri Pirko
2011-11-30 9:06 ` Thomas De Schampheleire
2011-12-05 9:50 ` Thomas De Schampheleire
2011-12-16 6:47 ` Thomas De Schampheleire
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.