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  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 <>
To:	Michal Soltys <>
Cc:	Eric Dumazet <>,
	Leonardo Uzcudun <>,
	yao zhao <>,
	"" <>
Subject: Re: VLAN 1 - Native

On Thu, Feb 2, 2012 at 4:17 AM, Michal Soltys <> 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
More majordomo info at

Powered by blists - more mailing lists