Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: David Lamparter <hidden>
Date: 2011-07-15 16:04:09
On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
quoted hunk ↗ jump to hunk
On 12 July 2011 12:36, David Lamparter [off-list ref] wrote:quoted
On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:quoted
I am still undecided on this. Understand the need, but don't like idea of bridge behaving in non-conforming manner. Will see if IEEE 802 committee has any input.The patch doesn't make the bridge behave nonconformant. The default mask is 0, which just keeps the old behaviour.Also as David points out in his review, after these diffs are applied we will be able to remove this@@ -166,6 +166,9 @@ struct sk_buff *br_handle_frame(struct sk_buff *skb) if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0) goto forward;Which is non-standard.
Actually, no, we might not be able to remove this (sorry for stating the opposite earlier). If we remove this, we can cause loops if we are a STP-disabled bridge on a STP-enabled ethernet. We would form a STP blackhole, causing more than one switch to assume responsibility for forwarding packets to our segment... While we could shift the burden for making a correct configuration onto the admin or the userspace tools (by setting the mask to 1 on a no-STP bridge), this would be a major change from previous behaviour and (more or less) count as regression. Either way I would consider removing that line a rather dangerous change. We didn't remove that line, let's stick with it and everything will stay as it used to be :)
So these diffs enable us to change the existing non-conforming behaviour to a conforming one.quoted
If you set the lowest 3 bits, yes, you can break your network.
Btw, a kernel warning for this would be useful i think, at least once. "You should only enable the lowest 3 bits for sniffing bridges." or so. -David