[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AE563C7.5070702@gmail.com>
Date: Mon, 26 Oct 2009 09:54:31 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Benny Amorsen <benny+usenet@...rsen.dk>
CC: Gertjan Hofman <gertjan_hofman@...oo.com>,
Matt Carlson <mcarlson@...adcom.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: VLAN and ARP failure on tg3 drivers
Benny Amorsen a écrit :
> Gertjan Hofman <gertjan_hofman@...oo.com> writes:
>
>> Dear Matt, Eric, Benny,
>>
>> Sorry about the slow response to your fast replies. I think Benny is
>> correct, the 'problem' lies in the fact that we were using a VLAN ID
>> of 0, without knowing its special significance. User error.
>>
>> I tested it with other VLAN id's (>0) and it appears to work fine. We
>> are not entirely sure we understand why it used to work with VLAN ID
>> 0 on the Broadcom chips and still does with a number of different
>> cards (with >2.6.27 kernels). What is the 'correct' behaviour for
>> this incorrect usage ?
>
> VLAN 0 isn't incorrect, it's just surprising. When you send a packet
> tagged with VLAN 0, it means that the packet should be interpreted as
> being the same VLAN as a completely untagged packet.
>
> So in theory, if both ends are using VLAN 0 and you aren't using eth0
> for anything, traffic should flow, at least if both ends are on the same
> kernel version. Feel free to debug why that isn't the case for you, of
> course...
>
VLAN id 0 is not usable on current kernel because we use 16 bits in skb to
store vlan_tci, and vlan_tci = 0 means there is no VLAN tagging.
We could use high order bit (0x8000) to tell if vlan tagging is set or not.
--
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