headers
Luca Lesinigo | 1 Aug 2007 14:09
Picon
Favicon

Jumbo frames support?

The documentation says the bridge will work as far as all interfaces have the same MTU, but I also read on this and other mailing lists people having problems when using jumbo frames.

What is the current status of jumbo frames support in the bridge?
It could also be useful to have the same info on the wiki page.

Thanks.

--
Luca Lesinigo

 

_______________________________________________
Bridge mailing list
Bridge <at> lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge
Permalink | Reply | 1 comment |
headers
Stephen Hemminger | 1 Aug 2007 17:48

Re: Jumbo frames support?

On Wed, 1 Aug 2007 14:09:45 +0200
Luca Lesinigo <luca <at> lesinigo.it> wrote:

> The documentation says the bridge will work as far as all interfaces  
> have the same MTU, but I also read on this and other mailing lists  
> people having problems when using jumbo frames.
> 
> What is the current status of jumbo frames support in the bridge?
> It could also be useful to have the same info on the wiki page.
> 
> Thanks.
> 
> --
> Luca Lesinigo
> 
> 

Bridge ignores frame size. The devices have to have same MTU
to work.
Permalink | Reply | 0 comments |
headers
Stephen Hemminger | 6 Aug 2007 11:05

Test

Due to recent spam overload, I had to flush the whole moderation queue.
No time to pick one possible good message from non-subscriber out of the 1000's of
bogus messages.
Permalink | Reply | 0 comments |
headers
Jussi Kivilinna | 9 Aug 2007 20:57
Picon
Picon

[PATCH] Fix typo in net/bridge/br_stp_if.c

Fixes a typo in net/bridge/br_stp_if.c

--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
 <at>  <at>  -132,7 +132,7  <at>  <at>  static void br_stp_start(struct net_bridge *br)
         } else {
                 br->stp_enabled = BR_KERNEL_STP;
                 printk(KERN_INFO "%s: starting userspace STP failed, "
-                               "staring kernel STP\n", br->dev->name);
+                               "starting kernel STP\n", br->dev->name);

                 /* To start timers on any ports left in blocking */
                 spin_lock_bh(&br->lock);
Permalink | Reply | 2 comments |
headers
Stephen Hemminger | 10 Aug 2007 10:43

Re: [PATCH] Fix typo in net/bridge/br_stp_if.c

On Thu, 09 Aug 2007 21:57:52 +0300
Jussi Kivilinna <jussi.kivilinna <at> pp.inet.fi> wrote:

> Fixes a typo in net/bridge/br_stp_if.c
> 
> --- a/net/bridge/br_stp_if.c
> +++ b/net/bridge/br_stp_if.c
>  <at>  <at>  -132,7 +132,7  <at>  <at>  static void br_stp_start(struct net_bridge *br)
>          } else {
>                  br->stp_enabled = BR_KERNEL_STP;
>                  printk(KERN_INFO "%s: starting userspace STP failed, "
> -                               "staring kernel STP\n", br->dev->name);
> +                               "starting kernel STP\n", br->dev->name);
> 
>                  /* To start timers on any ports left in blocking */
>                  spin_lock_bh(&br->lock);

Okay, but I can't forward patch through directly without Signed-off-by:
Permalink | Reply | 1 comment |
headers
Jussi Kivilinna | 11 Aug 2007 12:21
Picon
Picon

Re: [PATCH] Fix typo in net/bridge/br_stp_if.c

Stephen Hemminger kirjoitti:
> 
> Okay, but I can't forward patch through directly without Signed-off-by:
> 

Oh, sorry, didn't know about DCO/Signed-off-by, but I do now.

Fixes a typo in net/bridge/br_stp_if.c

Signed-off-by: Jussi Kivilinna <jussi.kivilinna <at> mbnet.fi>

--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
 <at>  <at>  -132,7 +132,7  <at>  <at>  static void br_stp_start(struct net_bridge *br)
         } else {
                 br->stp_enabled = BR_KERNEL_STP;
                 printk(KERN_INFO "%s: starting userspace STP failed, "
-                               "staring kernel STP\n", br->dev->name);
+                               "starting kernel STP\n", br->dev->name);

                 /* To start timers on any ports left in blocking */
                 spin_lock_bh(&br->lock);
Permalink | Reply | 0 comments |
headers
Stephen Hemminger | 14 Aug 2007 15:11

Re: BUG: when using 'brctl stp'

Bridge locking for /sys/class/net/br0/bridge/stp_enabled
was wrong.  Another bug in bridge utilities makes it such that
this interface, meant it wasn't being used.  The locking needs to be removed
from set_stp_state(), the lock is already acquired down in
br_stp_start()/br_stp_stop.

Signed-off-by: Stephen Hemminger <shemminger <at> linux-foundation.org>

--- a/net/bridge/br_sysfs_br.c	2007-07-16 14:24:18.000000000 +0100
+++ b/net/bridge/br_sysfs_br.c	2007-08-14 13:44:23.000000000 +0100
 <at>  <at>  -150,9 +150,7  <at>  <at>  static ssize_t show_stp_state(struct dev
 static void set_stp_state(struct net_bridge *br, unsigned long val)
 {
 	rtnl_lock();
-	spin_unlock_bh(&br->lock);
 	br_stp_set_enabled(br, val);
-	spin_lock_bh(&br->lock);
 	rtnl_unlock();
 }
Permalink | Reply | 0 comments |
headers
Lennert Buytenhek | 14 Aug 2007 15:18

Re: BUG: when using 'brctl stp'

On Tue, Aug 14, 2007 at 02:11:05PM +0100, Stephen Hemminger wrote:

> Bridge locking for /sys/class/net/br0/bridge/stp_enabled
> was wrong.  Another bug in bridge utilities makes it such that
> this interface, meant it wasn't being used.  The locking needs
> to be removed from set_stp_state(), the lock is already acquired
> down in br_stp_start()/br_stp_stop.

The 'locking' in set_stp_state() is actually dropping the lock
around the br_stp_set_enabled() invocation, not acquiring it:

>  <at>  <at>  -150,9 +150,7  <at>  <at>  static ssize_t show_stp_state(struct dev
>  static void set_stp_state(struct net_bridge *br, unsigned long val)
>  {
>  	rtnl_lock();
> -	spin_unlock_bh(&br->lock);
>  	br_stp_set_enabled(br, val);
> -	spin_lock_bh(&br->lock);
>  	rtnl_unlock();
>  }
Permalink | Reply | 0 comments |
headers
Lars Braeuer | 14 Aug 2007 15:34
Picon

Reset of setpathcost after link comes back up

In a redundant setup (2 bridges), I usally set the path cost of external ports
to 1 und internal ports to 100. So that the external port of the backup bridge
is in forwarding and the internal port in blocking state.

But, when the physical link goes down and comes back up (i.e. link failure or
cable unplug and replug) the path cost of the links automatically reset to
values like 4 and 19.

Is this a desired behaviour, shouldn't the path cost remain at the values specified?

I'm using bridge support in Kernel 2.6.19. As I can't test a new Kernel yet, I'm
just asking if this might be a bug and maybe someone knows if this has been
fixed lately?

Thanks in advance.

Best,

Lars
Permalink | Reply | 0 comments |
headers
Stephen Hemminger | 14 Aug 2007 15:50

[PATCH] bridge: sysfs locking fix.

Forget earlier patch, it is wrong...

The stp change code generates "sleeping function called from invalid context"
because rtnl_lock() called with BH disabled. This fixes it by not acquiring then
dropping the bridge lock.

Signed-off-by: Stephen Hemminger <shemminger <at> linux-foundation.org>

--- a/net/bridge/br_sysfs_br.c	2007-08-06 09:26:48.000000000 +0100
+++ b/net/bridge/br_sysfs_br.c	2007-08-14 14:29:52.000000000 +0100
 <at>  <at>  -147,20 +147,26  <at>  <at>  static ssize_t show_stp_state(struct dev
 	return sprintf(buf, "%d\n", br->stp_enabled);
 }

-static void set_stp_state(struct net_bridge *br, unsigned long val)
-{
-	rtnl_lock();
-	spin_unlock_bh(&br->lock);
-	br_stp_set_enabled(br, val);
-	spin_lock_bh(&br->lock);
-	rtnl_unlock();
-}

 static ssize_t store_stp_state(struct device *d,
 			       struct device_attribute *attr, const char *buf,
 			       size_t len)
 {
-	return store_bridge_parm(d, buf, len, set_stp_state);
+	struct net_bridge *br = to_bridge(d);
+	char *endp;
+	unsigned long val;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	val = simple_strtoul(buf, &endp, 0);
+	if (endp == buf)
+		return -EINVAL;
+
+	rtnl_lock();
+	br_stp_set_enabled(br, val);
+	rtnl_unlock();
+
 }
 static DEVICE_ATTR(stp_state, S_IRUGO | S_IWUSR, show_stp_state,
 		   store_stp_state);
Permalink | Reply | 0 comments |

Gmane