From: Andrew Morton <akpm@linux-foundation.org>
To: netdev@vger.kernel.org, Ben Greear <greearb@candelatech.com>
Cc: "bugme-daemon@kernel-bugs.osdl.org"
<bugme-daemon@kernel-bugs.osdl.org>,
tristan_schmelcher@alumni.uwaterloo.ca
Subject: Re: [Bugme-new] [Bug 8766] New: 802.1q VLAN stacking + REORDER_HDR is broken
Date: Mon, 16 Jul 2007 00:48:37 -0700 [thread overview]
Message-ID: <20070716004837.47cd60c1.akpm@linux-foundation.org> (raw)
In-Reply-To: <bug-8766-10286@http.bugzilla.kernel.org/>
On Sun, 15 Jul 2007 23:57:32 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8766
>
> Summary: 802.1q VLAN stacking + REORDER_HDR is broken
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.20
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: tristan_schmelcher@alumni.uwaterloo.ca
>
>
> Most recent kernel where this bug did not occur: Unknown
> Distribution: Several (see below)
> Hardware Environment: Several (see below)
> Software Environment: Several (see below)
> Problem Description: Combining VLAN stacking with the REORDER_HDR flag on
> either the inner or outer VLAN interface does not work. The computer puts only
> one VLAN tag on the wire.
>
> Steps to reproduce:
>
> vconfig add eth0 12
> ifconfig eth0.12 up
> vconfig add eth0.12 2
> ifconfig eth0.12.2 192.168.254.100
> (default is REORDER_HDR 1, so they both have it set)
> ping 192.168.254.101
> (no response)
>
> tcpdump -i eth0:
>
> 23:04:53.301156 vlan 2, p 0, arp who-has 192.168.254.101 tell tinygod2.local
> 23:04:54.301214 vlan 2, p 0, arp who-has 192.168.254.101 tell tinygod2.local
> 23:04:56.301326 vlan 2, p 0, arp who-has 192.168.254.101 tell tinygod2.local
>
> But:
>
> vconfig set_flag eth0.12 1 0
> vconfig set_flag eth0.12.2 1 0
> ping 192.168.254.101
> (Responses)
>
> tcpdump -i eth0:
>
> 23:10:44.932200 vlan 12, p 0, vlan 2, p 0, IP tinygod2.local > tinygod3.local:
> ICMP echo request, id 61054, seq 1, length 64
> 23:10:44.932364 vlan 12, p 0, vlan 2, p 0, IP tinygod3.local > tinygod2.local:
> ICMP echo reply, id 61054, seq 1, length 64
> 23:10:45.937238 vlan 12, p 0, vlan 2, p 0, IP tinygod2.local > tinygod3.local:
> ICMP echo request, id 61054, seq 2, length 64
> 23:10:45.937445 vlan 12, p 0, vlan 2, p 0, IP tinygod3.local > tinygod2.local:
> ICMP echo reply, id 61054, seq 2, length 64
> 23:10:46.937196 vlan 12, p 0, vlan 2, p 0, IP tinygod2.local > tinygod3.local:
> ICMP echo request, id 61054, seq 3, length 64
> 23:10:46.937401 vlan 12, p 0, vlan 2, p 0, IP tinygod3.local > tinygod2.local:
> ICMP echo reply, id 61054, seq 3, length 64
>
> If REORDER_HDR is 1 on only one of the two VLAN interfaces, it's still broken.
> However, if it's 1 on the inner interface and 0 on the outer one, then it's the
> outer tag that shows up on the wire, instead of the inner tag as in the rest of
> the cases.
>
> Note also that if the NIC card has VLAN acceleration then there's no problem
> with the above case. However, if you do 3 levels of stacked VLANs and put
> REORDER_HDR on one of the two inner ones, then it's broken in the analogous
> way.
>
> I have tested this on 3 computers, which between them have the same number of
> distinct distributions, kernel versions, NIC cards, and architectures. They
> are:
>
> (1) Kubuntu Feisty Fawn 2.6.20-15-generic on a Compaq AMD Athlon64 laptop with
> a Realtek RTL-8139 (used for the above output)
> (2) Debian Lenny 2.6.18-4-amd64 on a Dell Intel Core 2 Duo laptop with a
> Broadcom NetXtreme BCM5752 (which has acceleration)
> (3) uClinux 2.6.17-uc1 on a Nios II embedded system with the OpenCores MAC.
>
> Note that this appears to be the same bug as was long ago discovered by another
> user and described here:
> http://www.candelatech.com/pipermail/vlan/2004-December/000190.html
>
parent reply other threads:[~2007-07-16 7:48 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <bug-8766-10286@http.bugzilla.kernel.org/>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070716004837.47cd60c1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugme-daemon@kernel-bugs.osdl.org \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
--cc=tristan_schmelcher@alumni.uwaterloo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).