netdev - Re: VLAN 1

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 2 Feb 2012 08:33:12 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Michal Soltys <soltys@....info>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Leonardo Uzcudun <uzcudunl@...oo.it>,
	yao zhao <yao.development@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: VLAN 1 - Native

On Thu, Feb 2, 2012 at 4:17 AM, Michal Soltys <soltys@....info> wrote:
> On 02.02.2012 10:12, Eric Dumazet wrote:
>>
>> Le jeudi 02 février 2012 à 09:09 +0000, Leonardo Uzcudun a écrit :
>>>
>>> Hello Michal:
>>>
>>> It is working on kernel 3.0.0-15 Ubuntu. I've just to modify the
>>> ebtables command as:
>>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 101 -j DROP
>>> (protocol is a must when you use --vlan-id)
>>>
>>>
>>> I'll test it on kernel 2.6.32-5 Debian
>>>
>>>
>>> Just last question,in the case i should implement this kind of
>>> configuration in a kernel 2.6.31, should i backport/patch anything? is
>>> it a bad idea (running it on 2.6.31)?
>>
>>
>> This is going to be tough.
>>
>
> Btw, this (ebtables broute drop) method has been mentioned in bridge-nf faq
> for ages (through most/all 2.6 kernels at least) - and for the very purpose
> of directing tagged/not tagged traffic to proper bridge interfaces.
> Shouldn't 2.6.31 be pretty safe in that regard ?
>
> Or did you mean backporting/patching part ?
>
>
>> The point of Jesse Gross (and others) work was exactly to permit better
>> vlan/bridge integration/stacking.
>>
>
> Just to be sure - are those patches in any way changing / deprecating /
> conflicting with ebtables approach ?

Nothing in ebtables changed.  The part that is different here is
whether the vlan device or the bridge takes priority for tagged
frames.  So on new kernels your ebtables command to reject packets
from the bridge back to the device isn't necessary because the device
will just take it in the first place but it shouldn't break things.

Based on your description, I suspect that this will work fine on your
old kernel.  Part of the problem that was fixed is that the result was
hardware dependent.
--
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