netdev - bridge vs. bonding/pause frames (was: Forward EAPOL...)

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Jul 2011 17:16:26 +0200
From:	David Lamparter <equinox@...c24.net>
To:	Michał Mirosław <mirqus@...il.com>
Cc:	David Lamparter <equinox@...c24.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Nick Carter <ncarter100@...il.com>, netdev@...r.kernel.org,
	davem@...emloft.net
Subject: bridge vs. bonding/pause frames (was: Forward EAPOL...)

On Fri, Jul 01, 2011 at 04:58:56PM +0200, Michał Mirosław wrote:
[...]
> > We _MUST_NOT_ pass bonding frames in any case, but we
> > currently do that if STP is off. (cf. my earlier patch 1/2)
> 
> If you use linux box as a (invisible) L2 network tap, then you want to
> pass everything in the hub mode (including LACP/whatever).

We must not do that by default, this breaks bridges with bonding devices
as ports. I'm actively band-aiding that problem with ebtables on one of
my boxes currently.

How about I change "stp_forward_802local" to "forward_802local" and it
gets 3 values like:
- 0 (default) behave like a switch, if STP is on then drop all 16
  groups, if STP is off then drop :01 and :02
- 1 forward regular groups - drop :01 and :02, forward everything else
- 2 forward everything ("invisible tap mode")
optional:
- -1 drop all 16 groups even if STP is off (not needed, can be done with
  ebtables...)

btw, since the drivers should eat up pause frames, you're not a fully
invisible L2 tap anyway.


-David

--
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