On Wed, Aug 31, 2011 at 01:49:04PM -0700, Stephen Hemminger wrote:

On Wed, 31 Aug 2011 21:41:26 +0100
Nick Carter [off-list ref] wrote:

quoted

On 15 August 2011 19:25, Stephen Hemminger
[off-list ref] wrote:

quoted

On Mon, 15 Aug 2011 17:27:12 +0100
Nick Carter [off-list ref] wrote:

quoted

On 28 July 2011 16:41, Stephen Hemminger
[off-list ref] wrote:

quoted

On Wed, 27 Jul 2011 13:17:15 +0200
David Lamparter [off-list ref] wrote:

quoted

On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:

quoted

On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:

quoted

On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:

quoted

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.

P.S.: I'd like to once more stress this. In my opinion the patch should
be merged because it provides desireable functionality at a small cost
(one test, one knob) and __does not change any default behaviour__.

Stephen, anything new on this?

No.
Don't like adding yet another hack user visible API which will have
to be maintained for too long. But on the other hand I don't have
a better solution at my finger tips. If better idea doesn't come
along, then we can go with yours.

I have not noticed any other proposals and this thread has been open
for quite a while.  Have we waited long enough ? If so can this patch
be taken ?

I am testing an alternative. The problem with your proposal is that
it relies on the multicast address. It turns out there are people using
other addresses for the STP group address, so using that as a identifier
is incorrect.

If the chosen STP group address is in the local multicast group range
this patch will handle it.

David Lamparter has reviewed this patch and asked for it to be merged.
 This patch has at least two real world uses.  Ed needs this patch to
forward LLDP frames and I need this patch to forward 802.1X frames.

This patch has been out for review for 9 weeks and it still looks like
the best solution.

I prefer the netfilter solution because it is more general. We already have
a firewall solution why shouldn't this case be part of it?

Nick's patch *IS* the netfilter solution. Check where it jumps to:

forward:
	switch (p->state) {
	case BR_STATE_FORWARDING:
		rhook = rcu_dereference(br_should_route_hook);
		if (rhook) {
			if ((*rhook)(skb)) {
				*pskb = skb;
				return RX_HANDLER_PASS;

This calls ebt_broute, which returns true if the BROUTING chain says
"DROP", which means "don't bridge, deliver on physdev" in this context.

Your patch reinvents the wheel - new ebtables chain - and does not
allow any control without bridge-netfilter in kernel.

Nick's patch allows rudimentary control (enough for most cases i'd say)
when bridge-netfilter is disabled and full same-as-other-multicast
control when bridge-netfilter is enabled/loaded.


-David