linux-toradex.git/net/bridge, branch v3.0.16

bridge: leave carrier on for empty bridge

2011-11-11T17:36:49+00:00

[ Upstream commit b64b73d7d0c480f75684519c6134e79d50c1b341 ]

This resolves a regression seen by some users of bridging.
Some users use the bridge like a dummy device.
They expect to be able to put an IPv6 address on the device
with no ports attached. Although there are better ways of doing
this, there is no reason to not allow it.

Note: the bridge still will reflect the state of ports in the
bridge if there are any added.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: fix hang on removal of bridge via netlink

2011-11-11T17:36:24+00:00

[ Upstream commit 1ce5cce895309862d2c35d922816adebe094fe4a ]

Need to cleanup bridge device timers and ports when being bridge
device is being removed via netlink.

This fixes the problem of observed when doing:
 ip link add br0 type bridge
 ip link set dev eth1 master br0
 ip link set br0 up
 ip link del br0

which would cause br0 to hang in unregister_netdev because
of leftover reference count.

Reported-by: Sridhar Samudrala 
Signed-off-by: Stephen Hemminger 
Acked-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: fix a possible use after free

2011-10-03T18:40:56+00:00

[ Upstream commit 22df13319d1fec30b8f9bcaadc295829647109bb ]

br_multicast_ipv6_rcv() can call pskb_trim_rcsum() and therefore skb
head can be reallocated.

Cache icmp6_type field instead of dereferencing twice the struct
icmp6hdr pointer.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: Pseudo-header required for the checksum of ICMPv6

2011-10-03T18:40:56+00:00

[ Upstream commit 4b275d7efa1c4412f0d572fcd7f78ed0919370b3 ]

Checksum of ICMPv6 is not properly computed because the pseudo header is not used.
Thus, the MLD packet gets dropped by the bridge.

Signed-off-by: Zheng Yan 
Reported-by: Ang Way Chuang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: fix a possible net_device leak

2011-10-03T18:40:50+00:00

[ Upstream commit 11f3a6bdc2528d1ce2af50202dbf7138fdee1b34 ]

Jan Beulich reported a possible net_device leak in bridge code after
commit bb900b27a2f4 (bridge: allow creating bridge devices with netlink)

Reported-by: Jan Beulich 
Signed-off-by: Eric Dumazet 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: send proper message_age in config BPDU

2011-08-05T04:58:31+00:00

commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream.

A bridge topology with three systems:

      +------+  +------+
      | A(2) |--| B(1) |
      +------+  +------+
           \    /
          +------+
          | C(3) |
          +------+

What is supposed to happen:
 * bridge with the lowest ID is elected root (for example: B)
 * C detects that A->C is higher cost path and puts in blocking state

What happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.

The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.

In the standardmessage_age is supposed to be:
  the time since the generation of the Configuration BPDU by
  the Root that instigated the generation of this Configuration BPDU.

Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.

See also:
  https://bugzilla.vyatta.com/show_bug.cgi?id=7164

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: Always flood broadcast packets

2011-07-06T01:39:39+00:00

As is_multicast_ether_addr returns true on broadcast packets as
well, we need to explicitly exclude broadcast packets so that
they're always flooded.  This wasn't an issue before as broadcast
packets were considered to be an unregistered multicast group,
which were always flooded.  However, as we now only flood such
packets to router ports, this is no longer acceptable.

Reported-by: Michael Guntsche 
Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

bridge: Only flood unregistered groups to routers

2011-06-25T00:52:51+00:00

The bridge currently floods packets to groups that we have never
seen before to all ports.  This is not required by RFC4541 and
in fact it is not desirable in environment where traffic to
unregistered group is always present.

This patch changes the behaviour so that we only send traffic
to unregistered groups to ports marked as routers.

The user can always force flooding behaviour to any given port
by marking it as a router.

Note that this change does not apply to traffic to 224.0.0.X
as traffic to those groups must always be flooded to all ports.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

netpoll: copy dev name of slaves to struct netpoll

2011-06-19T23:13:01+00:00

Otherwise we will not see the name of the slave dev in error
message:

[  388.469446] (null):  doesn't support polling, aborting.

Signed-off-by: WANG Cong 
Signed-off-by: David S. Miller

IGMP snooping: set mrouters_only flag for IPv6 traffic properly

2011-06-17T03:14:13+00:00

Upon reception of a MGM report packet the kernel sets the mrouters_only flag
in a skb that is a clone of the original skb, which means that the bridge
loses track of MGM packets (cb buffers are tied to a specific skb and not
shared) and it ends up forwading join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: David S. Miller