Linux Ethernet Bridge

David Miller | 1 Dec 2011 05:02

Re: [PATCH] bridge: Cannot communicate with brX when its MAC address is changed

From: Koki Sanagi <sanagi.koki <at> jp.fujitsu.com>
Date: Wed, 30 Nov 2011 17:31:18 +0900

> When the MAC address of a bridge interface is changed, it cannot communicate
> with others. Because Whether or not a packet should be transferred to bridge
> interface depends on whether or not dst of a packet is in fdb and is_local=y.
> If we change MAC address of a bridge interface, it isn't in fdb.
> 
> This patch adds an condition that dst of a packet matches MAC address of
> a bridge interface to the conventional condition.
> 
> Signed-off-by: Koki Sanagi <sanagi.koki <at> jp.fujitsu.com>

This looks like a patch I've seen before, and in any event it makes
more sense to update the FDB when the MAC changes instead of adding a
special bypass rule.

Stephen?

> ---
>  net/bridge/br_input.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 5a31731..4e5c862 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
>  <at>  <at>  -94,7 +94,8  <at>  <at>  int br_handle_frame_finish(struct sk_buff *skb)
>  			skb2 = skb;
>

(Continue reading)

Stephen Hemminger | 1 Dec 2011 18:21

Re: [PATCH] bridge: Cannot communicate with brX when its MAC address is changed

On Wed, 30 Nov 2011 17:31:18 +0900
Koki Sanagi <sanagi.koki <at> jp.fujitsu.com> wrote:

> When the MAC address of a bridge interface is changed, it cannot communicate
> with others. Because Whether or not a packet should be transferred to bridge
> interface depends on whether or not dst of a packet is in fdb and is_local=y.
> If we change MAC address of a bridge interface, it isn't in fdb.
> 
> This patch adds an condition that dst of a packet matches MAC address of
> a bridge interface to the conventional condition.
> 
> Signed-off-by: Koki Sanagi <sanagi.koki <at> jp.fujitsu.com>
> ---
>  net/bridge/br_input.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 5a31731..4e5c862 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
>  <at>  <at>  -94,7 +94,8  <at>  <at>  int br_handle_frame_finish(struct sk_buff *skb)
>  			skb2 = skb;
>  
>  		br->dev->stats.multicast++;
> -	} else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
> +	} else if ((dst = __br_fdb_get(br, dest) && dst->is_local) ||
> +		   !compare_ether_addr(p->br->dev->dev_addr, dest)) {
>  		skb2 = skb;
>  		/* Do not forward the packet since it's local. */
>  		skb = NULL;

(Continue reading)

David Miller | 1 Dec 2011 19:02

Re: [PATCH] bridge: Cannot communicate with brX when its MAC address is changed

From: Stephen Hemminger <shemminger <at> vyatta.com>
Date: Thu, 1 Dec 2011 09:21:06 -0800

> Looked into using fdb to handle this, but then there would be fdb entries
> where the destination port entry was either NULL (or a dummy), and that
> would require a bunch of auditing of all usages and could introduce new
> bugs.
> 
> I am testing a patch that does same thing by moving compare_ether up
> to where broadcast is tested.

Stephen please fix this bug correctly.

The bug is that the FDB gets updated with the initial MAC address, but
doesn't get updated when the MAC address changes.

There is no other valid fix than to update the FDB when the MAC changes,
and making whatever is necessary for that to work.

I'm not applying a patch that adds a MAC address comparison here, because
you might was well not add the FDB entry in the first place if you're
going to add a hack like that.

Stephen Hemminger | 1 Dec 2011 19:44

Re: [PATCH] bridge: master device stuck in no-carrier state forever when in user-stp mode

On Fri, 25 Nov 2011 12:16:37 +0200
Vitalii Demianets <vitas <at> nppfactor.kiev.ua> wrote:

> When in user-stp mode, bridge master do not follow state of its slaves, so 
> after the following sequence of events it can stuck forever in no-carrier 
> state:
> 1) turn stp off
> 2) put all slaves down - master device will follow their state and also go in 
> no-carrier state
> 3) turn stp on with bridge-stp script returning 0 (go to the user-stp mode)
> Now bridge master won't follow slaves' state and will never reach running 
> state.
> 
> This patch solves the problem by making user-stp and kernel-stp behavior 
> similar regarding master following slaves' states.
> 
> Signed-off-by: Vitalii Demianets <vitas <at> nppfactor.kiev.ua>

This method works fine. David please apply to -net.

Acked-by: Stephen Hemminger <shemminger <at> vyatta.com>

David Miller | 1 Dec 2011 20:05

Re: [PATCH] bridge: master device stuck in no-carrier state forever when in user-stp mode

From: Stephen Hemminger <shemminger <at> vyatta.com>
Date: Thu, 1 Dec 2011 10:44:09 -0800

> On Fri, 25 Nov 2011 12:16:37 +0200
> Vitalii Demianets <vitas <at> nppfactor.kiev.ua> wrote:
> 
>> When in user-stp mode, bridge master do not follow state of its slaves, so 
>> after the following sequence of events it can stuck forever in no-carrier 
>> state:
>> 1) turn stp off
>> 2) put all slaves down - master device will follow their state and also go in 
>> no-carrier state
>> 3) turn stp on with bridge-stp script returning 0 (go to the user-stp mode)
>> Now bridge master won't follow slaves' state and will never reach running 
>> state.
>> 
>> This patch solves the problem by making user-stp and kernel-stp behavior 
>> similar regarding master following slaves' states.
>> 
>> Signed-off-by: Vitalii Demianets <vitas <at> nppfactor.kiev.ua>
> 
> This method works fine. David please apply to -net.
> 
> Acked-by: Stephen Hemminger <shemminger <at> vyatta.com>

Done.

Vitalii Demianets | 13 Dec 2011 10:36

Picon

[PATCH] bridge: push blocking slaves to forwarding when turning stp off

If there is a slave in blocking state when stp is turned off, that slave will 
remain in blocking state for indefinitely long time until interface state 
changed. We should push all blocking slaves into forwarding state after 
turning stp off.

Signed-off-by: Vitalii Demianets <vitas <at> nppfactor.kiev.ua>

---
 net/bridge/br_stp.c    |    5 ++++-
 net/bridge/br_stp_if.c |   10 +++++-----
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index dd147d7..aed7e21 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
 <at>  <at>  -415,7 +415,10  <at>  <at>  void br_port_state_selection(struct net_bridge *br)
 			} else {
 				p->config_pending = 0;
 				p->topology_change_ack = 0;
-				br_make_blocking(p);
+				if(br->stp_enabled == BR_NO_STP)
+					br_make_forwarding(p);
+				else
+					br_make_blocking(p);
 			}
 		}

diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 19308e3..38d8dd7 100644

(Continue reading)

Stephen Hemminger | 14 Dec 2011 01:16

Re: [PATCH] bridge: push blocking slaves to forwarding when turning stp off

On Tue, 13 Dec 2011 11:36:25 +0200
Vitalii Demianets <vitas <at> nppfactor.kiev.ua> wrote:

> If there is a slave in blocking state when stp is turned off, that slave will 
> remain in blocking state for indefinitely long time until interface state 
> changed. We should push all blocking slaves into forwarding state after 
> turning stp off.
> 
> Signed-off-by: Vitalii Demianets <vitas <at> nppfactor.kiev.ua>

Maybe. But if the port was in the blocking state then STP must have
decided there was a loop in the network if that port was used.
Therefore blindly putting the port into forwarding state could cause
disastrous network flood.

The user can force the port back out of blocking state (via sysfs).

Vitalii Demianets | 14 Dec 2011 10:32

Picon

Re: [PATCH] bridge: push blocking slaves to forwarding when turning stp off

On Wednesday 14 December 2011 02:16:13 Stephen Hemminger wrote:
> On Tue, 13 Dec 2011 11:36:25 +0200
>
> Vitalii Demianets <vitas <at> nppfactor.kiev.ua> wrote:
> > If there is a slave in blocking state when stp is turned off, that slave
> > will remain in blocking state for indefinitely long time until interface
> > state changed. We should push all blocking slaves into forwarding state
> > after turning stp off.
> >
> > Signed-off-by: Vitalii Demianets <vitas <at> nppfactor.kiev.ua>
>
> Maybe. But if the port was in the blocking state then STP must have
> decided there was a loop in the network if that port was used.
> Therefore blindly putting the port into forwarding state could cause
> disastrous network flood.
>
>
> The user can force the port back out of blocking state (via sysfs).
>

1) That blocking state in the absence of STP is not stable. It will eventually 
flip to forwarding sooner or later on the first call of 
br_port_state_selection(). For example, when user changes MAC address on 
another slave. Or even worse - when any other slave of the bridge changes its 
carrier state. Don't think user wants such unpredictable state changes.

2) There is also another drawback of not pushing ports into forwarding state 
after turning off USER_STP mode. Possible scenario is:
  a) bridge in USER_STP mode, all ports are in non-forwarding state (blocking, 
learning)

(Continue reading)

Vitalii Demianets | 20 Dec 2011 11:59

Picon

Re: [PATCH] bridge: push blocking slaves to forwarding when turning stp off

Hello, Stephen!
I can not understand your silence.
There are issues fixed by the patch in question. For example, if the interface 
is left in blocking state after stp was turned off, that state is not 
stable - it can flip to forwarding state in unpredictable times, e.g. when 
_any other_ slave of the bridge goes up or down. Do you think user wants 
exactly that unpredictable state change?
Also, the code in question in function br_stp_stop(), namely 
br_port_state_selection(br) call, does exactly nothing except wasting cpu 
cycles. Isn't it worth fixing?

--

-- 
Vitalii Demianets

Stephen Hemminger | 20 Dec 2011 19:11

Re: [PATCH] bridge: push blocking slaves to forwarding when turning stp off

On Tue, 20 Dec 2011 12:59:11 +0200
Vitalii Demianets <vitas <at> nppfactor.kiev.ua> wrote:

> Hello, Stephen!
> I can not understand your silence.
> There are issues fixed by the patch in question. For example, if the interface 
> is left in blocking state after stp was turned off, that state is not 
> stable - it can flip to forwarding state in unpredictable times, e.g. when 
> _any other_ slave of the bridge goes up or down. Do you think user wants 
> exactly that unpredictable state change?
> Also, the code in question in function br_stp_stop(), namely 
> br_port_state_selection(br) call, does exactly nothing except wasting cpu 
> cycles. Isn't it worth fixing?
> 

I had to go do real work last week.
Let me test and look at it more detail.
There is no urgency, the problem has existed for many years.

Group

gmane.linux.network.bridge.

Search Archive

Page

1 | 2

Articles in period: 17

December 2011

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[PATCHv4 net-next 0/2] Add two new flags to bridge. (30 Apr 2013)
[PATCHv2 net-next 0/2] Add two new flags to bridge. (29 Apr 2013)
[PATCH net-next 0/2] Add some new flags to bridges. (29 Apr 2013)
[PATCH v2 net-next 0/6] Allow bridge to function in non-promisc mode (19 Apr 2013)
Configuration-messages from root switch hello-timer not forwarded (19 Apr 2013)
[PATCH] bridge: Add missing include for in6_addr (18 Apr 2013)
[PATCH] Notify userspace about bridge learning MAC on new port (15 Apr 2013)
bridging and VLANs (15 Apr 2013)
[PATCH net] bridge: make user modified path cost sticky (14 Apr 2013)
[PATCH 0/3] bridge: implement restricted forwarding policy (8 Apr 2013)
network namespace + bridge visibility (28 Mar 2013)
[PATCH net-next] bridge: remove unused variable ifm (28 Mar 2013)
[PATCH] bridge: fix crash when set mac address of br interface (23 Mar 2013)
[PATCH net-next] bridge: avoid br_ifinfo_notify when nothing changed (23 Mar 2013)
[PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener (20 Mar 2013)
[PATCH v2] net: add ETH_P_802_3_MIN (28 Mar 2013)
[PATCH] bridge: netfilter: use PTR_RET instead of IS_ERR + PTR_ERR (12 Mar 2013)
[PATCH -next] bridge: using for_each_set_bit to simplify the code (11 Mar 2013)
[PATCH -next] bridge: using for_each_set_bit_from to simplify the code (11 Mar 2013)
[PATCH] bridge-utils: Fix compile against linux-3.8.x (6 Mar 2013)
Problem with multicast traffic when using network bridging (23 Feb 2013)

Archives

8	May 2013
60	April 2013
80	March 2013
66	February 2013
140	January 2013
71	December 2012
20	November 2012
12	October 2012
12	September 2012
55	August 2012
10	July 2012
15	June 2012
18	May 2012
3	April 2012
40	March 2012
21	February 2012
17	January 2012
17	December 2011
39	November 2011
2	October 2011
18	September 2011
27	August 2011
6	July 2011
16	June 2011
51	May 2011
35	April 2011
100	March 2011
43	February 2011
23	January 2011
24	December 2010
21	November 2010
53	October 2010
10	September 2010
41	August 2010
20	July 2010
43	June 2010
47	May 2010
57	April 2010
102	March 2010
31	February 2010
82	January 2010
46	December 2009
103	November 2009
8	October 2009
11	September 2009
92	August 2009
27	July 2009
81	June 2009
143	May 2009
96	April 2009
82	March 2009
23	February 2009
44	January 2009
12	December 2008
39	November 2008
30	October 2008
31	September 2008
28	August 2008
43	July 2008
55	June 2008
51	May 2008
54	April 2008
67	March 2008
16	February 2008
33	January 2008
13	December 2007
52	November 2007
29	October 2007
35	September 2007
36	August 2007
20	July 2007
17	June 2007
30	May 2007
72	April 2007
73	March 2007
44	February 2007
38	January 2007
50	December 2006
38	November 2006
38	October 2006
32	September 2006
37	August 2006
37	July 2006
29	June 2006
40	May 2006
34	April 2006
19	March 2006
19	February 2006
21	January 2006
40	December 2005
38	November 2005
27	October 2005
30	September 2005
38	August 2005
30	July 2005
38	June 2005
51	May 2005
24	April 2005
47	March 2005
20	February 2005
97	January 2005
37	December 2004
15	November 2004
6	October 2004
52	September 2004
99	August 2004
71	July 2004
70	June 2004
71	May 2004
56	April 2004
54	March 2004
39	February 2004
37	January 2004
9	December 2003
11	November 2003
40	October 2003
48	September 2003
44	August 2003
64	July 2003
87	June 2003
78	May 2003
83	April 2003
75	March 2003
148	February 2003
68	January 2003
65	December 2002
84	November 2002
121	October 2002
82	September 2002
6	July 2002
89	June 2002
113	May 2002
103	April 2002
1	September 2001

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template