[Bridge] bridge problem when one interface is in blocking mode

[Bridge] bridge problem when one interface is in blocking mode

[wang dengyi]

Hi,

We have a simple bridge setup but the ping (and other
network traffic) does not work reliably. After tracing
the code, it looks like a software bug. Since bridge
software is been running by thousands of people. I
guess I am wrong.  Anyway, here is the problem.

There are 2 boxes and each one has 2 interfaces, 1
ethernet and 1 wifi. STP is enabled for the bridge to
avoid the loop. So the box 1 has wifi in the blocking
mode. When we ping from box 1 to box 2, lots of
packages lost. Ping from box 2 to box 1 does not has
this problem. 

After we tracing the code, we noticed that the box try
to using wifi to send the packages which is in
blocking mode. This happens because the ath0 is
returned from the forwarding database. It's
implemented in __br_fdb_get(br, dest). 

From the etherreal, I noticed, that the STP package is
broadcast from the box 2. From the function
br_handle_frame(), if a stp package is received, it
will update the forwarding database. Since the STP
package is sent/received by both interfaces, the wifi
(blocking) received the package and update the
forwarding database too. So, __br_fdb_get() will
returns the wifi card sometimes. And then, the package
is lost. 

Regards,

Dengyi Wang







       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: [Bridge] bridge problem when one interface is in blocking mode

[Stephen Hemminger]

On Wed, 22 Aug 2007 15:36:30 -0700 (PDT)
wang dengyi <dy_wang@yahoo.com> wrote:

> Hi,
> 
> We have a simple bridge setup but the ping (and other
> network traffic) does not work reliably. After tracing
> the code, it looks like a software bug. Since bridge
> software is been running by thousands of people. I
> guess I am wrong.  Anyway, here is the problem.
> 
> There are 2 boxes and each one has 2 interfaces, 1
> ethernet and 1 wifi. STP is enabled for the bridge to
> avoid the loop. So the box 1 has wifi in the blocking
> mode. When we ping from box 1 to box 2, lots of
> packages lost. Ping from box 2 to box 1 does not has
> this problem. 
> 
> After we tracing the code, we noticed that the box try
> to using wifi to send the packages which is in
> blocking mode. This happens because the ath0 is
> returned from the forwarding database. It's
> implemented in __br_fdb_get(br, dest). 
> 
> >From the etherreal, I noticed, that the STP package is
> broadcast from the box 2. From the function
> br_handle_frame(), if a stp package is received, it
> will update the forwarding database. Since the STP
> package is sent/received by both interfaces, the wifi
> (blocking) received the package and update the
> forwarding database too. So, __br_fdb_get() will
> returns the wifi card sometimes. And then, the package
> is lost. 
> 
> Regards,
> 
> Dengyi Wang

What kernel version are you using?

Bridging over wifi doesn't usually work unless the wifi driver
has WDS support.  In wifi when bridging the driver would need
to add an additional header that gives intermediate hop information:
See:
	http://www.cisco.com/en/US/docs/wireless/access_point/1300/12.2_15_JA/configuration/guide/o13wds.html


> 
> 
> 
> 
> 
> 
>        
> ____________________________________________________________________________________
> Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
> http://sims.yahoo.com/  
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge


-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [Bridge] bridge problem when one interface is in blocking mode

[wang dengyi]

Hi Stephen,

Here is the detail
kernel version: 2.6.14
architecture: PPC
ehternet: from the processor mpc5200b
wifi manufactor: Netgate 5004 MP, Atheros chipset
wifi driver: madwifi 0.91
WDS on wifi: enabled.

I guess it's an issue combined by ethernet driver/wifi
driver and bridge. Is there anything you suspect that
I can check? 

I believe the 2 actions: updating forwarding database
when a stp package is received and delivering the
package based on the forwarding database, are correct.
I must miss something. For example, STP detection set
an interface as blocking and remove it from the
forwarding database? It's just my wild guess. 

By the way, I found Bartek reported the same issue on
2.6.11.12 and 2.6.13.2. Here is the link:
https://lists.linux-foundation.org/pipermail/bridge/2005-October/004710.html
He has 3 ethernet nic for each machine and his fix is
to update the forwarding database only when the port
is in learning or forwarding state.

Regards,

Dengyi



 

--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:

> On Wed, 22 Aug 2007 15:36:30 -0700 (PDT)
> wang dengyi <dy_wang@yahoo.com> wrote:
> 
> > Hi,
> > 
> > We have a simple bridge setup but the ping (and
> other
> > network traffic) does not work reliably. After
> tracing
> > the code, it looks like a software bug. Since
> bridge
> > software is been running by thousands of people. I
> > guess I am wrong.  Anyway, here is the problem.
> > 
> > There are 2 boxes and each one has 2 interfaces, 1
> > ethernet and 1 wifi. STP is enabled for the bridge
> to
> > avoid the loop. So the box 1 has wifi in the
> blocking
> > mode. When we ping from box 1 to box 2, lots of
> > packages lost. Ping from box 2 to box 1 does not
> has
> > this problem. 
> > 
> > After we tracing the code, we noticed that the box
> try
> > to using wifi to send the packages which is in
> > blocking mode. This happens because the ath0 is
> > returned from the forwarding database. It's
> > implemented in __br_fdb_get(br, dest). 
> > 
> > >From the etherreal, I noticed, that the STP
> package is
> > broadcast from the box 2. From the function
> > br_handle_frame(), if a stp package is received,
> it
> > will update the forwarding database. Since the STP
> > package is sent/received by both interfaces, the
> wifi
> > (blocking) received the package and update the
> > forwarding database too. So, __br_fdb_get() will
> > returns the wifi card sometimes. And then, the
> package
> > is lost. 
> > 
> > Regards,
> > 
> > Dengyi Wang
> 
> What kernel version are you using?
> 
> Bridging over wifi doesn't usually work unless the
> wifi driver
> has WDS support.  In wifi when bridging the driver
> would need
> to add an additional header that gives intermediate
> hop information:
> See:
> 
>
http://www.cisco.com/en/US/docs/wireless/access_point/1300/12.2_15_JA/configuration/guide/o13wds.html
> 
> 
> > 
> > 
> > 
> > 
> > 
> > 
> >        
> >
>
____________________________________________________________________________________
> > Moody friends. Drama queens. Your life? Nope! -
> their life, your story. Play Sims Stories at Yahoo!
> Games.
> > http://sims.yahoo.com/  
> > _______________________________________________
> > Bridge mailing list
> > Bridge@lists.linux-foundation.org
> >
>
https://lists.linux-foundation.org/mailman/listinfo/bridge
> 
> 
> -- 
> Stephen Hemminger <shemminger@linux-foundation.org>
> 



      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

Re: [Bridge] bridge problem when one interface is in blocking mode

[Stephen Hemminger]

On Thu, 23 Aug 2007 11:17:44 -0700 (PDT)
wang dengyi <dy_wang@yahoo.com> wrote:

> Hi Stephen,
> 
> Here is the detail
> kernel version: 2.6.14
> architecture: PPC
> ehternet: from the processor mpc5200b
> wifi manufactor: Netgate 5004 MP, Atheros chipset
> wifi driver: madwifi 0.91
> WDS on wifi: enabled.
> 
> I guess it's an issue combined by ethernet driver/wifi
> driver and bridge. Is there anything you suspect that
> I can check? 
> 
> I believe the 2 actions: updating forwarding database
> when a stp package is received and delivering the
> package based on the forwarding database, are correct.
> I must miss something. For example, STP detection set
> an interface as blocking and remove it from the
> forwarding database? It's just my wild guess. 
> 
> By the way, I found Bartek reported the same issue on
> 2.6.11.12 and 2.6.13.2. Here is the link:
> https://lists.linux-foundation.org/pipermail/bridge/2005-October/004710.html
> He has 3 ethernet nic for each machine and his fix is
> to update the forwarding database only when the port
> is in learning or forwarding state.
>

There was a bug fix in later kernel (2.6.19) that causes the forwarding
database to be purged when STP decides not to use interface.

Re: [Bridge] bridge problem when one interface is in blocking mode

[wang dengyi]

--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:

> On Thu, 23 Aug 2007 11:17:44 -0700 (PDT)
> wang dengyi <dy_wang@yahoo.com> wrote:
> 
> > Hi Stephen,
> > 
> > Here is the detail
> > kernel version: 2.6.14
> > architecture: PPC
> > ehternet: from the processor mpc5200b
> > wifi manufactor: Netgate 5004 MP, Atheros chipset
> > wifi driver: madwifi 0.91
> > WDS on wifi: enabled.
> > 
> > I guess it's an issue combined by ethernet
> driver/wifi
> > driver and bridge. Is there anything you suspect
> that
> > I can check? 
> > 
> > I believe the 2 actions: updating forwarding
> database
> > when a stp package is received and delivering the
> > package based on the forwarding database, are
> correct.
> > I must miss something. For example, STP detection
> set
> > an interface as blocking and remove it from the
> > forwarding database? It's just my wild guess. 
> > 
> > By the way, I found Bartek reported the same issue
> on
> > 2.6.11.12 and 2.6.13.2. Here is the link:
> >
>
https://lists.linux-foundation.org/pipermail/bridge/2005-October/004710.html
> > He has 3 ethernet nic for each machine and his fix
> is
> > to update the forwarding database only when the
> port
> > is in learning or forwarding state.
> >
> 
> There was a bug fix in later kernel (2.6.19) that
> causes the forwarding
> database to be purged when STP decides not to use
> interface.
> 

Hi Stephen, 

I merged the bridge code from the kernel source tree
2.6.19. But it's the same thing: packages are sent
through the blocking interface. Anyway, I am worried
that something is missing when I merged the code.
Could you give me more information about the patch? If
it's possible, please send me  your patch for 2.6.19?
Thank you very much. 

At the same time, I am looking for the relationship
between blocking interface and the forwarding table
from the stp source code. No luck until now. Any hint?


Regards,

Dengyi



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: [Bridge] bridge problem when one interface is in blocking mode

[Stephen Hemminger]

On Wed, 29 Aug 2007 14:27:44 -0700 (PDT)
wang dengyi <dy_wang@yahoo.com> wrote:

> --- Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> 
> > On Thu, 23 Aug 2007 11:17:44 -0700 (PDT)
> > wang dengyi <dy_wang@yahoo.com> wrote:
> > 
> > > Hi Stephen,
> > > 
> > > Here is the detail
> > > kernel version: 2.6.14
> > > architecture: PPC
> > > ehternet: from the processor mpc5200b
> > > wifi manufactor: Netgate 5004 MP, Atheros chipset
> > > wifi driver: madwifi 0.91
> > > WDS on wifi: enabled.
> > > 
> > > I guess it's an issue combined by ethernet
> > driver/wifi
> > > driver and bridge. Is there anything you suspect
> > that
> > > I can check? 
> > > 
> > > I believe the 2 actions: updating forwarding
> > database
> > > when a stp package is received and delivering the
> > > package based on the forwarding database, are
> > correct.
> > > I must miss something. For example, STP detection
> > set
> > > an interface as blocking and remove it from the
> > > forwarding database? It's just my wild guess. 
> > > 
> > > By the way, I found Bartek reported the same issue
> > on
> > > 2.6.11.12 and 2.6.13.2. Here is the link:
> > >
> >
> https://lists.linux-foundation.org/pipermail/bridge/2005-October/004710.html
> > > He has 3 ethernet nic for each machine and his fix
> > is
> > > to update the forwarding database only when the
> > port
> > > is in learning or forwarding state.
> > >
> > 
> > There was a bug fix in later kernel (2.6.19) that
> > causes the forwarding
> > database to be purged when STP decides not to use
> > interface.
> > 
> 
> Hi Stephen, 
> 
> I merged the bridge code from the kernel source tree
> 2.6.19. But it's the same thing: packages are sent
> through the blocking interface. Anyway, I am worried
> that something is missing when I merged the code.
> Could you give me more information about the patch? If
> it's possible, please send me  your patch for 2.6.19?
> Thank you very much. 
> 
> At the same time, I am looking for the relationship
> between blocking interface and the forwarding table
> from the stp source code. No luck until now. Any hint?
> 
> 

Perhaps you are getting packets in over the blocked device,
and they are getting into the forwarding table?

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [Bridge] bridge problem when one interface is in blocking mode

[wang dengyi]

--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:

> On Wed, 29 Aug 2007 14:27:44 -0700 (PDT)
> wang dengyi <dy_wang@yahoo.com> wrote:
> 
> > --- Stephen Hemminger
> > <shemminger@linux-foundation.org> wrote:
> > 
> > > On Thu, 23 Aug 2007 11:17:44 -0700 (PDT)
> > > wang dengyi <dy_wang@yahoo.com> wrote:
> > > 
> > > > Hi Stephen,
> > > > 
> > > > Here is the detail
> > > > kernel version: 2.6.14
> > > > architecture: PPC
> > > > ehternet: from the processor mpc5200b
> > > > wifi manufactor: Netgate 5004 MP, Atheros
> chipset
> > > > wifi driver: madwifi 0.91
> > > > WDS on wifi: enabled.
> > > > 
> > > > I guess it's an issue combined by ethernet
> > > driver/wifi
> > > > driver and bridge. Is there anything you
> suspect
> > > that
> > > > I can check? 
> > > > 
> > > > I believe the 2 actions: updating forwarding
> > > database
> > > > when a stp package is received and delivering
> the
> > > > package based on the forwarding database, are
> > > correct.
> > > > I must miss something. For example, STP
> detection
> > > set
> > > > an interface as blocking and remove it from
> the
> > > > forwarding database? It's just my wild guess. 
> > > > 
> > > > By the way, I found Bartek reported the same
> issue
> > > on
> > > > 2.6.11.12 and 2.6.13.2. Here is the link:
> > > >
> > >
> >
>
https://lists.linux-foundation.org/pipermail/bridge/2005-October/004710.html
> > > > He has 3 ethernet nic for each machine and his
> fix
> > > is
> > > > to update the forwarding database only when
> the
> > > port
> > > > is in learning or forwarding state.
> > > >
> > > 
> > > There was a bug fix in later kernel (2.6.19)
> that
> > > causes the forwarding
> > > database to be purged when STP decides not to
> use
> > > interface.
> > > 
> > 
> > Hi Stephen, 
> > 
> > I merged the bridge code from the kernel source
> tree
> > 2.6.19. But it's the same thing: packages are sent
> > through the blocking interface. Anyway, I am
> worried
> > that something is missing when I merged the code.
> > Could you give me more information about the
> patch? If
> > it's possible, please send me  your patch for
> 2.6.19?
> > Thank you very much. 
> > 
> > At the same time, I am looking for the
> relationship
> > between blocking interface and the forwarding
> table
> > from the stp source code. No luck until now. Any
> hint?
> > 
> > 
> 
> Perhaps you are getting packets in over the blocked
> device,
> and they are getting into the forwarding table?
> 
> -- 
> Stephen Hemminger <shemminger@linux-foundation.org>
> 

The answer is yes and no. We do receive packets from
the blocked device. But they are BPDU packets only. 
The fowarding database is updated because the BPDU
package is received. 

Here is the chart of our network.

          +-------------+   
ath0  +---+   bridge 1  +---+ eth0
      |   +-------------+   |
      |                     | 
      |                     | 
      |   +-------------+   |
ath0  +---+   bridge 2  +---+ eth0
          +-------------+    
Both bridge has the same Mac address as the ath0. And
ath0 on the bridge 1 is blocked. So when the BPDU
packet is received on the ath0 of bridge 1, it update
the forwarding table and the following network packets
will go through the ath0 which is in blocking mode. 

Regards,

Dengyi


       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

Re: [Bridge] bridge problem when one interface is in blocking mode

[Srinivas M.A.]

>
> The answer is yes and no. We do receive packets from
> the blocked device. But they are BPDU packets only.
> The fowarding database is updated because the BPDU
> package is received.
>
> Here is the chart of our network.
>
>           +-------------+
> ath0  +---+   bridge 1  +---+ eth0
>       |   +-------------+   |
>       |                     |
>       |                     |
>       |   +-------------+   |
> ath0  +---+   bridge 2  +---+ eth0
>           +-------------+
> Both bridge has the same Mac address as the ath0. And
> ath0 on the bridge 1 is blocked. So when the BPDU
> packet is received on the ath0 of bridge 1, it update
> the forwarding table and the following network packets
> will go through the ath0 which is in blocking mode.

I read this and first thought there should be no problem since each
port has its own MAC address. But the bridge MAC address is that of
one port, so this is a problem for getting to the bridge interface
itself.
The 802.1D docs also say that the forwarding database should be
updated only when the state of the port that received the packet
allows learning.

[Bridge] [PATCH] bridge: packets leaking out of disabled/blocked ports

[Stephen Hemminger]

This patch fixes some packet leakage in bridge.  The bridging code
was allowing forward table entries to be generated even if a device
was being blocked. The fix is to not add forwarding database entries
unless the port is active.

The bug arose as part of the conversion to processing STP frames
through normal receive path (in 2.6.17).

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

--- a/net/bridge/br_fdb.c	2007-08-30 07:49:01.000000000 -0700
+++ b/net/bridge/br_fdb.c	2007-08-30 11:40:36.000000000 -0700
@@ -384,6 +384,11 @@ void br_fdb_update(struct net_bridge *br
 	if (hold_time(br) == 0)
 		return;
 
+	/* ignore packets unless we are using this port */
+	if (!(source->state == BR_STATE_LEARNING ||
+	      source->state == BR_STATE_FORWARDING))
+		return;
+
 	fdb = fdb_find(head, addr);
 	if (likely(fdb)) {
 		/* attempt to update an entry for a local interface */
--- a/net/bridge/br_input.c	2007-08-30 07:49:01.000000000 -0700
+++ b/net/bridge/br_input.c	2007-08-30 12:19:57.000000000 -0700
@@ -101,9 +101,8 @@ static int br_handle_local_finish(struct
 {
 	struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);
 
-	if (p && p->state != BR_STATE_DISABLED)
+	if (p)
 		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
-
 	return 0;	 /* process further */
 }
 

[Bridge] Re: [PATCH] bridge: packets leaking out of disabled/blocked ports

[John W. Linville]

On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote:
> This patch fixes some packet leakage in bridge.  The bridging code
> was allowing forward table entries to be generated even if a device
> was being blocked. The fix is to not add forwarding database entries
> unless the port is active.

Seems reasonable -- ACK

John
-- 
John W. Linville
linville@tuxdriver.com

[Bridge] Re: [PATCH] bridge: packets leaking out of disabled/blocked ports

[David Miller]

From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 30 Aug 2007 16:03:13 -0400

> On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote:
> > This patch fixes some packet leakage in bridge.  The bridging code
> > was allowing forward table entries to be generated even if a device
> > was being blocked. The fix is to not add forwarding database entries
> > unless the port is active.
> 
> Seems reasonable -- ACK

Applied, thanks.