[PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

Introduce sysfs ../bridge/group_fwd_mask attribute so users can
configure which group mac addresses are forwarded.

These diffs do not change the default behaviour of bridge.ko.  By
changing the group_fwd_mask value users can select any combination of
the 01-80-C2-00-00-00 - 01-80-C2-00-00-0F addresses to be forwarded.

Signed-off-by: Nick Carter <ncarter100@gmail.com>

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index d9d1e2b..bb25e49 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -214,6 +214,7 @@ static struct net_device *new_bridge_dev(struct
net *net, const char *name)
 	br->topology_change = 0;
 	br->topology_change_detected = 0;
 	br->ageing_time = 300 * HZ;
+	br->group_fwd_mask = 0;

 	br_netfilter_rtable_init(br);

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 90e985b..80b94f4 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -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;

+		if (p->br->group_fwd_mask & (1 << dest[5]))
+			goto forward;
+
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
 			    NULL, br_handle_local_finish))
 			return NULL;	/* frame consumed by filter */
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 4e1b620..d5aa164 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -244,6 +244,13 @@ struct net_bridge
 	struct timer_list		multicast_query_timer;
 #endif

+	/* Each bit used to match the LSB of the IEEE 802.1D group address
+	 * 01-80-C2-00-00-00 bit 0
+	 * ..
+	 * 01-80-C2-00-00-0F bit 15
+	 */
+	u16				group_fwd_mask;
+
 	struct timer_list		hello_timer;
 	struct timer_list		tcn_timer;
 	struct timer_list		topology_change_timer;
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 5c1e555..f3cced5 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -679,6 +679,28 @@ static DEVICE_ATTR(nf_call_arptables, S_IRUGO | S_IWUSR,
 		   show_nf_call_arptables, store_nf_call_arptables);
 #endif

+static ssize_t show_group_fwd_mask(struct device *d, struct
device_attribute *attr,
+				char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	return sprintf(buf, "%d\n", br->group_fwd_mask);
+}
+
+static int set_group_fwd_mask(struct net_bridge *br, unsigned long val)
+{
+	br->group_fwd_mask = (u16)val;
+	return 0;
+}
+
+static ssize_t store_group_fwd_mask(struct device *d,
+				 struct device_attribute *attr, const char *buf,
+				 size_t len)
+{
+	return store_bridge_parm(d, buf, len, set_group_fwd_mask);
+}
+static DEVICE_ATTR(group_fwd_mask, S_IRUGO | S_IWUSR, show_group_fwd_mask,
+		   store_group_fwd_mask);
+
 static struct attribute *bridge_attrs[] = {
 	&dev_attr_forward_delay.attr,
 	&dev_attr_hello_time.attr,
@@ -698,6 +720,7 @@ static struct attribute *bridge_attrs[] = {
 	&dev_attr_gc_timer.attr,
 	&dev_attr_group_addr.attr,
 	&dev_attr_flush.attr,
+	&dev_attr_group_fwd_mask.attr,
 #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
 	&dev_attr_multicast_router.attr,
 	&dev_attr_multicast_snooping.attr,

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Fri, Jul 01, 2011 at 10:21:44PM +0100, Nick Carter wrote:
> Introduce sysfs ../bridge/group_fwd_mask attribute so users can
> configure which group mac addresses are forwarded.
> 
> These diffs do not change the default behaviour of bridge.ko.  By
> changing the group_fwd_mask value users can select any combination of
> the 01-80-C2-00-00-00 - 01-80-C2-00-00-0F addresses to be forwarded.
> 
> Signed-off-by: Nick Carter <ncarter100@gmail.com>

Hm. Makes it very easy to shoot yourself in the foot, but...

> +	br->group_fwd_mask = 0;

... but the default is safe, so we're following the unix philosophy of
handing out the gun to shoot yourself :)

Reviewed-by: David Lamparter <equinox@diac24.net>


PS:
> @@ -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;

Not sure if we still need the STP one when we have the mask, it should
probably go away for consistency. It would change existing behaviour
though... either way it can be a separate patch.

> +		if (p->br->group_fwd_mask & (1 << dest[5]))
> +			goto forward;
> +
>  		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
>  			    NULL, br_handle_local_finish))
>  			return NULL;	/* frame consumed by filter */

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

On 1 July 2011 23:37, David Lamparter <equinox@diac24.net> wrote:
> On Fri, Jul 01, 2011 at 10:21:44PM +0100, Nick Carter wrote:
>> Introduce sysfs ../bridge/group_fwd_mask attribute so users can
>> configure which group mac addresses are forwarded.
>>
>> These diffs do not change the default behaviour of bridge.ko.  By
>> changing the group_fwd_mask value users can select any combination of
>> the 01-80-C2-00-00-00 - 01-80-C2-00-00-0F addresses to be forwarded.
>>
>> Signed-off-by: Nick Carter <ncarter100@gmail.com>
>
> Hm. Makes it very easy to shoot yourself in the foot, but...
>
>> +     br->group_fwd_mask = 0;
>
> ... but the default is safe, so we're following the unix philosophy of
> handing out the gun to shoot yourself :)
>
> Reviewed-by: David Lamparter <equinox@diac24.net>
>
>
> PS:
>> @@ -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;
>
> Not sure if we still need the STP one when we have the mask, it should
> probably go away for consistency. It would change existing behaviour
> though... either way it can be a separate patch.
Yes I agree.  Probably best to wait until the user space tools are
updated to support the new mask, so users can easily configure a
workaround to the change in behaviour.  I'm happy to update brctl to
support the mask, I pretty much have the diffs already.
Nick

>
>> +             if (p->br->group_fwd_mask & (1 << dest[5]))
>> +                     goto forward;
>> +
>>               if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
>>                           NULL, br_handle_local_finish))
>>                       return NULL;    /* frame consumed by filter */
>

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

Updated diffs so they apply to net-next (Original diffs were based off 2.6.38).

Any chance of getting these diffs applied?  The default behaviour of
the bridge code is unchanged.  They solve the problem of
authenticating a virtual 802.1x supplicant machine against an external
802.1X authenticator.  It is also a general solution that allows the
forwarding of any combination of the IEEE 802 local multicast groups.

Signed-off-by: Nick Carter <ncarter100@gmail.com>
Reviewed-by: David Lamparter <equinox@diac24.net>

 net/bridge/br_device.c   |    1 +
 net/bridge/br_input.c    |    3 +++
 net/bridge/br_private.h  |    8 ++++++++
 net/bridge/br_sysfs_br.c |   23 +++++++++++++++++++++++
 4 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 32b8f9f..573ed8c 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -366,6 +366,7 @@ void br_dev_setup(struct net_device *dev)
 	br->bridge_hello_time = br->hello_time = 2 * HZ;
 	br->bridge_forward_delay = br->forward_delay = 15 * HZ;
 	br->ageing_time = 300 * HZ;
+	br->group_fwd_mask = 0;

 	br_netfilter_rtable_init(br);
 	br_stp_timer_init(br);
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..3bee262 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -170,6 +170,9 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
 		if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
 			goto forward;

+		if (p->br->group_fwd_mask & (1 << dest[5]))
+			goto forward;
+
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
 			    NULL, br_handle_local_finish)) {
 			return RX_HANDLER_CONSUMED; /* consumed by filter */
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 54578f2..413fcec 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -244,6 +244,14 @@ struct net_bridge
 	struct timer_list		multicast_query_timer;
 #endif

+	/* Each bit used to match the least significant nibble of the
+	 * IEEE 802.1D group address.
+	 * 01-80-C2-00-00-00 bit 0
+	 * ..
+	 * 01-80-C2-00-00-0F bit 15
+	 */
+	u16				group_fwd_mask;
+
 	struct timer_list		hello_timer;
 	struct timer_list		tcn_timer;
 	struct timer_list		topology_change_timer;
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 68b893e..d77f681 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -646,6 +646,28 @@ static DEVICE_ATTR(nf_call_arptables, S_IRUGO | S_IWUSR,
 		   show_nf_call_arptables, store_nf_call_arptables);
 #endif

+static ssize_t show_group_fwd_mask(struct device *d,
+				   struct device_attribute *attr, char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	return sprintf(buf, "%d\n", br->group_fwd_mask);
+}
+
+static int set_group_fwd_mask(struct net_bridge *br, unsigned long val)
+{
+	br->group_fwd_mask = (u16)val;
+	return 0;
+}
+
+static ssize_t store_group_fwd_mask(struct device *d,
+				    struct device_attribute *attr,
+				    const char *buf, size_t len)
+{
+	return store_bridge_parm(d, buf, len, set_group_fwd_mask);
+}
+static DEVICE_ATTR(group_fwd_mask, S_IRUGO | S_IWUSR, show_group_fwd_mask,
+		   store_group_fwd_mask);
+
 static struct attribute *bridge_attrs[] = {
 	&dev_attr_forward_delay.attr,
 	&dev_attr_hello_time.attr,
@@ -665,6 +687,7 @@ static struct attribute *bridge_attrs[] = {
 	&dev_attr_gc_timer.attr,
 	&dev_attr_group_addr.attr,
 	&dev_attr_flush.attr,
+	&dev_attr_group_fwd_mask.attr,
 #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
 	&dev_attr_multicast_router.attr,
 	&dev_attr_multicast_snooping.attr,

On 1 July 2011 22:21, Nick Carter <ncarter100@gmail.com> wrote:
> Introduce sysfs ../bridge/group_fwd_mask attribute so users can
> configure which group mac addresses are forwarded.
>
> These diffs do not change the default behaviour of bridge.ko.  By
> changing the group_fwd_mask value users can select any combination of
> the 01-80-C2-00-00-00 - 01-80-C2-00-00-0F addresses to be forwarded.
>
> Signed-off-by: Nick Carter <ncarter100@gmail.com>
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index d9d1e2b..bb25e49 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -214,6 +214,7 @@ static struct net_device *new_bridge_dev(struct
> net *net, const char *name)
>        br->topology_change = 0;
>        br->topology_change_detected = 0;
>        br->ageing_time = 300 * HZ;
> +       br->group_fwd_mask = 0;
>
>        br_netfilter_rtable_init(br);
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 90e985b..80b94f4 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -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;
>
> +               if (p->br->group_fwd_mask & (1 << dest[5]))
> +                       goto forward;
> +
>                if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
>                            NULL, br_handle_local_finish))
>                        return NULL;    /* frame consumed by filter */
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 4e1b620..d5aa164 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -244,6 +244,13 @@ struct net_bridge
>        struct timer_list               multicast_query_timer;
>  #endif
>
> +       /* Each bit used to match the LSB of the IEEE 802.1D group address
> +        * 01-80-C2-00-00-00 bit 0
> +        * ..
> +        * 01-80-C2-00-00-0F bit 15
> +        */
> +       u16                             group_fwd_mask;
> +
>        struct timer_list               hello_timer;
>        struct timer_list               tcn_timer;
>        struct timer_list               topology_change_timer;
> diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
> index 5c1e555..f3cced5 100644
> --- a/net/bridge/br_sysfs_br.c
> +++ b/net/bridge/br_sysfs_br.c
> @@ -679,6 +679,28 @@ static DEVICE_ATTR(nf_call_arptables, S_IRUGO | S_IWUSR,
>                   show_nf_call_arptables, store_nf_call_arptables);
>  #endif
>
> +static ssize_t show_group_fwd_mask(struct device *d, struct
> device_attribute *attr,
> +                               char *buf)
> +{
> +       struct net_bridge *br = to_bridge(d);
> +       return sprintf(buf, "%d\n", br->group_fwd_mask);
> +}
> +
> +static int set_group_fwd_mask(struct net_bridge *br, unsigned long val)
> +{
> +       br->group_fwd_mask = (u16)val;
> +       return 0;
> +}
> +
> +static ssize_t store_group_fwd_mask(struct device *d,
> +                                struct device_attribute *attr, const char *buf,
> +                                size_t len)
> +{
> +       return store_bridge_parm(d, buf, len, set_group_fwd_mask);
> +}
> +static DEVICE_ATTR(group_fwd_mask, S_IRUGO | S_IWUSR, show_group_fwd_mask,
> +                  store_group_fwd_mask);
> +
>  static struct attribute *bridge_attrs[] = {
>        &dev_attr_forward_delay.attr,
>        &dev_attr_hello_time.attr,
> @@ -698,6 +720,7 @@ static struct attribute *bridge_attrs[] = {
>        &dev_attr_gc_timer.attr,
>        &dev_attr_group_addr.attr,
>        &dev_attr_flush.attr,
> +       &dev_attr_group_fwd_mask.attr,
>  #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
>        &dev_attr_multicast_router.attr,
>        &dev_attr_multicast_snooping.attr,
>

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Stephen Hemminger]

On Sun, 10 Jul 2011 17:04:30 +0100
Nick Carter <ncarter100@gmail.com> wrote:

> Updated diffs so they apply to net-next (Original diffs were based off 2.6.38).
> 
> Any chance of getting these diffs applied?  The default behaviour of
> the bridge code is unchanged.  They solve the problem of
> authenticating a virtual 802.1x supplicant machine against an external
> 802.1X authenticator.  It is also a general solution that allows the
> forwarding of any combination of the IEEE 802 local multicast groups.
> 
> Signed-off-by: Nick Carter <ncarter100@gmail.com>
> Reviewed-by: David Lamparter <equinox@diac24.net>

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.

Also, don't want to build more knobs in with sysfs that are per-bridge.
Eventually, the plan is to make all the setting per-port with sysctl's
like IPv6.

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> On Sun, 10 Jul 2011 17:04:30 +0100
> Nick Carter <ncarter100@gmail.com> wrote:
> 
> > Updated diffs so they apply to net-next (Original diffs were based off 2.6.38).
> > 
> > Any chance of getting these diffs applied?  The default behaviour of
> > the bridge code is unchanged.  They solve the problem of
> > authenticating a virtual 802.1x supplicant machine against an external
> > 802.1X authenticator.  It is also a general solution that allows the
> > forwarding of any combination of the IEEE 802 local multicast groups.
> > 
> > Signed-off-by: Nick Carter <ncarter100@gmail.com>
> > Reviewed-by: David Lamparter <equinox@diac24.net>
> 
> 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.

If you set the lowest 3 bits, yes, you can break your network. But so
does enabling proxy_arp in most cases. And there are reasonable use
cases for it, both 802.1X forwarding and fully-transparent* packet
capture bridges benefit from it. And the latter is something I wouldn't
wish to move to userspace either.

Maybe we should add a warning if the lowest 3 bits are set, like
"you have enabled forwarding of STP/Pause/Bond frames. This can
thoroughly break your network."

* excl. pause frames, sadly - those get eaten by hw/driver...

> Also, don't want to build more knobs in with sysfs that are per-bridge.
> Eventually, the plan is to make all the setting per-port with sysctl's
> like IPv6.

This setting doesn't make sense per-port IMHO. Also, sysctl?!


-David

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> On Sun, 10 Jul 2011 17:04:30 +0100
>> Nick Carter <ncarter100@gmail.com> wrote:
>>
>> > Updated diffs so they apply to net-next (Original diffs were based off 2.6.38).
>> >
>> > Any chance of getting these diffs applied?  The default behaviour of
>> > the bridge code is unchanged.  They solve the problem of
>> > authenticating a virtual 802.1x supplicant machine against an external
>> > 802.1X authenticator.  It is also a general solution that allows the
>> > forwarding of any combination of the IEEE 802 local multicast groups.
>> >
>> > Signed-off-by: Nick Carter <ncarter100@gmail.com>
>> > Reviewed-by: David Lamparter <equinox@diac24.net>
>>
>> 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.

So these diffs enable us to change the existing non-conforming
behaviour to a conforming one.
>
> If you set the lowest 3 bits, yes, you can break your network. But so
> does enabling proxy_arp in most cases. And there are reasonable use
> cases for it, both 802.1X forwarding and fully-transparent* packet
> capture bridges benefit from it. And the latter is something I wouldn't
> wish to move to userspace either.
>
> Maybe we should add a warning if the lowest 3 bits are set, like
> "you have enabled forwarding of STP/Pause/Bond frames. This can
> thoroughly break your network."
>
> * excl. pause frames, sadly - those get eaten by hw/driver...
>
>> Also, don't want to build more knobs in with sysfs that are per-bridge.
>> Eventually, the plan is to make all the setting per-port with sysctl's
>> like IPv6.
>
> This setting doesn't make sense per-port IMHO. Also, sysctl?!
I agree this setting should be per-bridge.  Also not taking something
that is needed today, because it will make some possible future change
slightly harder, seems a bit conservative to me.
Nick
>
>
> -David
>
>

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> >> 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.
>
> > 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

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > >> 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__.

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > > >> 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?

-David

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Stephen Hemminger]

On Wed, 27 Jul 2011 13:17:15 +0200
David Lamparter <equinox@diac24.net> wrote:

> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > > > >> 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.

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

On 28 July 2011 16:41, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> On Wed, 27 Jul 2011 13:17:15 +0200
> David Lamparter <equinox@diac24.net> wrote:
>
>> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
>> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
>> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
>> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
>> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> > > > >> 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 ?

Thanks,
Nick

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Stephen Hemminger]

On Mon, 15 Aug 2011 17:27:12 +0100
Nick Carter <ncarter100@gmail.com> wrote:

> On 28 July 2011 16:41, Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> > On Wed, 27 Jul 2011 13:17:15 +0200
> > David Lamparter <equinox@diac24.net> wrote:
> >
> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> >> > > > >> 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.

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Nick Carter]

On 15 August 2011 19:25, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> On Mon, 15 Aug 2011 17:27:12 +0100
> Nick Carter <ncarter100@gmail.com> wrote:
>
>> On 28 July 2011 16:41, Stephen Hemminger
>> <shemminger@linux-foundation.org> wrote:
>> > On Wed, 27 Jul 2011 13:17:15 +0200
>> > David Lamparter <equinox@diac24.net> wrote:
>> >
>> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
>> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
>> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
>> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
>> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> >> > > > >> 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.

Could this patch be merged please ?

Thanks,
Nick

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Stephen Hemminger]

On Wed, 31 Aug 2011 21:41:26 +0100
Nick Carter <ncarter100@gmail.com> wrote:

> On 15 August 2011 19:25, Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> > On Mon, 15 Aug 2011 17:27:12 +0100
> > Nick Carter <ncarter100@gmail.com> wrote:
> >
> >> On 28 July 2011 16:41, Stephen Hemminger
> >> <shemminger@linux-foundation.org> wrote:
> >> > On Wed, 27 Jul 2011 13:17:15 +0200
> >> > David Lamparter <equinox@diac24.net> wrote:
> >> >
> >> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> >> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> >> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> >> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> >> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> >> >> > > > >> 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?

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Ed Swierk]

On Wed, Aug 31, 2011 at 1:49 PM, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> 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?

For my application, I just want the bridge to forward all link-local
frames as well as regular frames between a pair of interfaces. It
seems a little odd to use a mechanism like netfilter to tell the
bridge _not_ to drop frames that would otherwise be dropped.

But other than that minor issue, my strong preference is that either
your or Nick's patch be committed as soon as possible :-)

--Ed

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[David Lamparter]

On Wed, Aug 31, 2011 at 01:49:04PM -0700, Stephen Hemminger wrote:
> On Wed, 31 Aug 2011 21:41:26 +0100
> Nick Carter <ncarter100@gmail.com> wrote:
> 
> > On 15 August 2011 19:25, Stephen Hemminger
> > <shemminger@linux-foundation.org> wrote:
> > > On Mon, 15 Aug 2011 17:27:12 +0100
> > > Nick Carter <ncarter100@gmail.com> wrote:
> > >
> > >> On 28 July 2011 16:41, Stephen Hemminger
> > >> <shemminger@linux-foundation.org> wrote:
> > >> > On Wed, 27 Jul 2011 13:17:15 +0200
> > >> > David Lamparter <equinox@diac24.net> wrote:
> > >> >
> > >> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > >> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > >> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > >> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > >> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > >> >> > > > >> 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

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Benjamin Poirier]

On 11-07-28 08:41, Stephen Hemminger wrote:
> On Wed, 27 Jul 2011 13:17:15 +0200
> David Lamparter <equinox@diac24.net> wrote:
> 
> > On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > > > > >> 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.

For virtualization-related problems, how about using macvtap? No need to
change the bridging code.

I had also previously submitted a patch to forward reserved group
addresses through the bridge. This was towards the goal of forwarding
EAPOL frames for virtual machines. I have since come to the realization
that one can use macvtap to achieve that instead. This forgoes the
bridge and offers better performance too.

I have tested macvtap + kvm to authenticate/authorize a virtual machine
connected to a 802.1X enabled switch. I used the instructions here for
macvtap:
http://virt.kernelnewbies.org/MacVTap
and tested with an HP switch and wpa_supplicant on the guest.

-Ben
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Ed Swierk]

On Fri, Aug 12, 2011 at 3:45 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> If you turn off STP that is what it does right now. It forwards STP
> and 802.1X frames. The patch was only related to turning on STP
> and still expecting 802.1X frames to be forwarded (in violation of
> the spec).

As far as I can tell, the only case currently where the bridge
forwards a packet destined for a link-local multicast address is

  if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)

dest[5] != 0 for an LLDP packet, whose destination address is
01-80-C2-00-00-0E per IEEE 802.1AB-2005.

--Ed

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Stephen Hemminger]

On Fri, 12 Aug 2011 15:37:54 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:

> I'm using elaborate combinations of bridges, tunnels and vlans to make
> remote switches many hops away appear as though they're locally
> connected to a virtual machine. In this application the bridges are
> just used to forward traffic between a pair of interfaces. I need the
> bridge to behave as much like a dumb 2-port hub as possible,
> forwarding LLDP frames that 802.1d-compliant bridges normally drop.

If you turn off STP that is what it does right now. It forwards STP
and 802.1X frames. The patch was only related to turning on STP
and still expecting 802.1X frames to be forwarded (in violation of
the spec).

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

[Ed Swierk]

Stephen Hemminger wrote:
> 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.

+1 for applying Nick Carter's patch adding a group_fwd_mask setting to
the bridge driver
(http://www.spinics.net/lists/netdev/msg169607.html).

I'm using elaborate combinations of bridges, tunnels and vlans to make
remote switches many hops away appear as though they're locally
connected to a virtual machine. In this application the bridges are
just used to forward traffic between a pair of interfaces. I need the
bridge to behave as much like a dumb 2-port hub as possible,
forwarding LLDP frames that 802.1d-compliant bridges normally drop.

I solemnly swear I will not pester the netdev list when I melt down my
LAN by inadvertently forwarding STP frames.

--Ed