gmane.linux.network.bridge

[PATCHv2 net-next] bridge: Set vlan_features to allowoffloads on vlans.

Vlad Yasevich — 2013-05-22T17:49:34

When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures.  Set vlan_fatures to
be equivalent to hw_fatures.

Signed-off-by: Vlad Yasevich <vyasevic< at >redhat.com>
---
 net/bridge/br_device.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 9673128..75f3239 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
< at >< at > -22,6 +22,9 < at >< at >
 #include <asm/uaccess.h>
 #include "br_private.h"
 
+#define COMMON_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA | \
+ NETIF_F_GSO_MASK | NETIF_F_HW_CSUM)
+
 /* net device transmit always called with BH disabled */
 netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
 {
< at >< at > -346,12 +349,10 < at >< at > void br_dev_setup(struct net_device *dev)
 dev->tx_queue_len = 0;
 dev->priv_flags = IFF_EBRIDGE;
 
-dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA |

[PATCH] bridge: Set vlan_features to allow offloads onvlans.

Vlad Yasevich — 2013-05-22T15:46:30

When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures.  Set vlan_fatures to
be equivalent to hw_fatures.

Signed-off-by: Vlad Yasevich <vyasevic< at >redhat.com>
---
 net/bridge/br_device.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 9673128..126f2c2 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
< at >< at > -352,6 +352,7 < at >< at > void br_dev_setup(struct net_device *dev)
 dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA |
    NETIF_F_GSO_MASK | NETIF_F_HW_CSUM |
    NETIF_F_HW_VLAN_CTAG_TX;
+dev->vlan_features = dev->hw_features;
 
 br->dev = dev;
 spin_lock_init(&br->lock);

[PATCH] bridge: netfilter: using strlcpy() instead ofstrncpy()

Chen Gang — 2013-05-17T08:07:22

'name' has already set all zero when it is defined, so not need let
strncpy() to pad it again.

'name' is a string, better always let is NUL terminated, so use
strlcpy() instead of strncpy().


Signed-off-by: Chen Gang <gang.chen< at >asianux.com>
---
 net/bridge/netfilter/ebtables.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 3d110c4..ac78024 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
< at >< at > -1339,7 +1339,7 < at >< at > static inline int ebt_make_matchname(const struct ebt_entry_match *m,
 
 /* ebtables expects 32 bytes long names but xt_match names are 29 bytes
    long. Copy 29 bytes and fill remaining bytes with zeroes. */
-strncpy(name, m->u.match->name, sizeof(name));
+strlcpy(name, m->u.match->name, sizeof(name));
 if (copy_to_user(hlp, name, EBT_FUNCTION_MAXNAMELEN))
 return -EFAULT;
 return 0;
< at >< at > -1351,7 +1351,7 < at >< at > static inline int ebt_make_watchername(const struct

[PATCH] Add support for netconsole driver used on bridge device with VIF attached

Yuval Shaia — 2013-05-01T11:55:01

When starting a VM which has virtual interface attached to the same bridge (i.e vif = [type=netfront,bridge=xenbr0'] in vm.cfg) which is used for netconsole the
following message appears (after about 60 seconds) and VM creation operation fails.
     Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Note:
When trying to do the opposite, i.e. first create VM and then run
netconsole we got the error #524 - vif2.0 doesn't support polling,
aborting.

Here is my network setup:
----------                              ----------
| VM A1  |------vif1.0----->|           | Host B |
|--------|                  |--xenbr0   |        |
| Host A |--bond0 (eth0)--->|           |        |
----------          |                   ----------
                    |                        |
                    V                        V
--------------------------------------------------
|                      LAN                       |
--------------------------------------------------

I'm using netconso

[PATCHv4 net-next 0/2] Add two new flags to bridge.

Vlad Yasevich — 2013-04-30T18:18:45

The following series adds 2 new flags to bridge.  One flag allows
the user to control whether mac learning is performed on the interface
or not.  By default mac learning is on.
The other flag allows the user to control whether unicast traffic
is flooded (send without an fdb) to a given unicast port.  Default is
on.

Changes since v4:
 - Implemented Stephen's suggestions.

Changes since v2:
 - removed unused "unlock" tag.

Changes since v1:
 - Integrated suggestion from MST to not impact RTM_NEWNEIGH and to
   skip lookups when learning is disabled.

Vlad Yasevich (2):
  bridge: Add flag to control mac learning.
  bridge: Add a flag to control unicast packet flood.

 include/uapi/linux/if_link.h |    2 ++
 net/bridge/br_device.c       |    8 ++++----
 net/bridge/br_fdb.c          |   17 ++++++++++++++---
 net/bridge/br_forward.c      |   14 +++++++++-----
 net/bridge/br_if.c           |    2 +-
 net/bridge/br_input.c        |    9 ++++++---
 net/bridge/br_netlink.c      |   10 +++++++++-
 net/bridge/br_privat

[PATCHv2 net-next 0/2] Add two new flags to bridge.

Vlad Yasevich — 2013-04-29T17:35:43

The following series adds 2 new flags to bridge.  One flag allows
the user to control whether mac learning is performed on the interface
or not.  By default mac learning is on.
The other flag allows the user to control whether unicast traffic
is flooded (send without an fdb) to a given unicast port.  Default is
on.

Changes since v1:
 - Integrated suggestion from MST to not impact RTM_NEWNEIGH and to
   skip lookups when learning is disabled.

Vlad Yasevich (2):
  bridge: Add flag to control mac learning.
  bridge: Add a flag to control unicast packet flood.

 include/uapi/linux/if_link.h |    2 ++
 net/bridge/br_device.c       |    8 ++++----
 net/bridge/br_fdb.c          |   17 ++++++++++++++---
 net/bridge/br_forward.c      |   14 +++++++++-----
 net/bridge/br_if.c           |    2 +-
 net/bridge/br_input.c        |    9 ++++++---
 net/bridge/br_netlink.c      |   10 +++++++++-
 net/bridge/br_private.h      |    7 +++++--
 net/bridge/br_sysfs_if.c     |    4 ++++
 9 files changed, 54 insertions(+), 19 del

[PATCH net-next 0/2] Add some new flags to bridges.

Vlad Yasevich — 2013-04-29T15:58:20

The follows series adds 2 new flags to bridge.  One flag allows
the user to control whether mac learning is performed on the interface
or not.  By default mac learning is on.
The other flag allows the user to control whether unicast traffic
is flooded (send without an fdb) to a given unicast port.  Default is
on.

Vlad Yasevich (2):
  bridge: Add flag to control mac learning.
  bridge: Add a flag to control unicast packet flood.

 include/uapi/linux/if_link.h |    2 ++
 net/bridge/br_device.c       |    8 ++++----
 net/bridge/br_fdb.c          |    4 ++++
 net/bridge/br_forward.c      |   14 +++++++++-----
 net/bridge/br_if.c           |    2 +-
 net/bridge/br_input.c        |    9 ++++++---
 net/bridge/br_netlink.c      |   10 +++++++++-
 net/bridge/br_private.h      |    7 +++++--
 net/bridge/br_sysfs_if.c     |    4 ++++
 9 files changed, 44 insertions(+), 16 deletions(-)

[PATCH v2 net-next 0/6] Allow bridge to function innon-promisc mode

Vlad Yasevich — 2013-04-19T20:52:44

This series is an almost complete rework of the prior attempt
to make the bridge function in non-promisc mode.  In this series
the "promiscuity" of an interface is dynamically determined and
the interface may transition from/to promiscuous mode based on
bridge configuration.

The series keeps an idea of an "uplink" port.  That is still user
designated.
The series also adds a concept of "dynamic" bridge port.  This is
the default state of the port and means that the user has not
specified any static FDBs for that port.
Once a user has added a static FDB entry to port and also specified
an "uplink" flag for that FDB, the mac address from that FDB is
added to the bridge hw address list and synched down to uplinks.
"Uplinks" are always considered dynamic ports even if a static entry
has been added for them.
Promiscuity is determined by the number of dynamic ports.  If there
are no dynamic ports (i.e all ports have static FDBs set), then we
know all the neighbors and can switch promisc off on all of the ports.
If

Configuration-messages from root switch hello-timer notforwarded

Pieter De Baets — 2013-04-19T17:55:32

Hi everyone,

I'm trying to set up a simple ring-netwerk using a managed switch as root
(an HP ProCurve 2512) and some mini-ITX boards with 2 network-interfaces.

Initial setup is working fine but when I add a node B to a deeper level (so
[switch] → [node A] → *[node B]* → [node C] → [switch]) I get the following
error-messages on node about 20 seconds after initialization complets (when
the message age timer expires)

br0: port 1(eth0) neighbor 8000.00:0d:b9:1c:66:20 lost


which causes a reconfiguration of the network, and if there's any loops
causes blocking and relearning of the tree, with lots of traffic being
generated.

net_ratelimit: 35664 callbacks suppressed


When I look at one of the upstream-nodes (A or C) they do receive hello
messages within the message window (on their designated port) but do not
seem to forward them to their other interfaces.

The bridges are created with the following commands:

brctl addbr br0

brctl stp on

brctl addif br0 eth0

brctl addif br0 eth1

ifconfig br0

[PATCH] bridge: Add missing include for in6_addr

Sven Eckelmann — 2013-04-18T09:17:38

ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 ("bridge: export multicast database
via netlink") added "struct br_mdb_entry" which includes an element using the
type "struct in6_addr". The file linux/if_bridge.h is part of the uapi and not
defining this type in this file or its includes causes build failures in
userspace applications.

Signed-off-by: Sven Eckelmann <sven< at >open-mesh.com>
---
 include/uapi/linux/if_bridge.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index 2d70d79..8e3f287 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
< at >< at > -14,6 +14,7 < at >< at >
 #define _UAPI_LINUX_IF_BRIDGE_H
 
 #include <linux/types.h>
+#include <linux/in6.h>
 
 #define SYSFS_BRIDGE_ATTR"bridge"
 #define SYSFS_BRIDGE_FDB"brforward"

[PATCH] Notify userspace about bridge learning MAC on newport

michael-dev — 2013-04-15T10:29:10

Hi,

currently, the userspace is informed about the port the MAC is learned 
on a bridge and about the bridge removing the MAC from its forwarding 
table, but not when the MAC is learned on a different port. This is 
inconsistent and makes it difficult for applications to keep track of 
all MACs learned by a bridge on a subset of its ports.

Please find attached a patch that fixes this by sending an RTM_NEWNEIGH 
message when the forwarding destination port changes.

Regards,
  M. BraunNotify userspace about bridge learning MAC on new port

Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.

Signed-off-by: Michael Braun <michael-dev< at >fami-braun.de>

--- a/net/bridge/br_fdb.c2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_f

bridging and VLANs

Benjamin Scarlet — 2013-04-15T12:15:23

I'm trying to understand the current and future state of bridging VLANs. I see there's been patch activity on this list, so I'm hoping someone here will be kind enough to explain.

I currently bridge VLANs, using commands like 

$ brctl addbr neta
$ brctl addif neta eth0.100
...

This works for me, mostly. Should it? Is this interface going to change?

Thanks,
Ben Scarlet

[PATCH net] bridge: make user modified path cost sticky

Stephen Hemminger — 2013-04-14T00:06:07

Keep a STP port path cost value if it was set by a user.
Don't replace it with the link-speed based path cost
whenever the link goes down and comes back up.

Reported-by: Roopa Prabhu <roopa< at >cumulusnetworks.com>
Signed-off-by: Stephen Hemminger <stephen< at >networkplumber.org>

---
 net/bridge/br_if.c      |    3 ++-
 net/bridge/br_private.h |    1 +
 net/bridge/br_stp_if.c  |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

--- a/net/bridge/br_private.h2013-03-14 14:22:58.155958025 -0700
+++ b/net/bridge/br_private.h2013-04-13 09:16:41.712531648 -0700
< at >< at > -156,6 +156,7 < at >< at > struct net_bridge_port
 #define BR_BPDU_GUARD           0x00000002
 #define BR_ROOT_BLOCK0x00000004
 #define BR_MULTICAST_FAST_LEAVE0x00000008
+#define BR_ADMIN_COST0x00000010
 
 #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
 u32multicast_startup_queries_sent;
--- a/net/bridge/br_stp_if.c2013-03-07 18:12:53.885287247 -0800
+++ b/net/bridge/br_stp_if.c2013-04-13 09:19:58.437979528 -0700
< at >< at > -288,6 +288,7 < at >< at > int br_stp_set_path_cost(str

[PATCH 0/3] bridge: implement restricted forwarding policy

Antonio Quartulli — 2013-04-08T17:41:00

Hello,

with this patchset I would like to introduce a new feature to be added to the
bridge module that is later going to be one of the building block of a
distributed technique implemented using batman-adv.

The scenario where we want to play is a Layer2 mesh network handled by
the batman-adv module. For who may not know how it works, batman-adv creates a
sort of "extended broadcast domain" shared among nodes that are not directly
connected to each other.
This mechanism provides every node the view of the batman-adv network
as it was a very big Ethernet switch.


The goal we want to achieve by adding this feature consists in selecting a
subset of the interfaces available on all the hosts participating to the mesh
network and to prevent packets from being forwarded from one of them to another.

Looking again at the "very big switch" abstraction this would allow a mesh
network administrator to define a sort of "not forwarding policy network wide"
between some of the big switch's port.

This patchset is intro

network namespace + bridge visibility

Марк Коренберг — 2013-03-28T18:17:16

==========================
mmarkk< at >imac:~# brctl addbr qwe
mmarkk< at >imac:~# unshare -n /bin/bash
root< at >imac:~# ip link
14: lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root< at >imac:~# brctl show
bridge name bridge id STP enabled interfaces
qwe 8000.000000000000 no
root< at >imac:~# brctl delbr qwe
bridge qwe doesn't exist; can't delete it
=============================

So, network device is not available, but present in list of bridges. This
is the bug, as I think.

Reproducible in linux kernels 3.8.2 and 3.2.0

[PATCH net-next] bridge: remove unused variable ifm

Hong Zhiguo — 2013-03-28T16:21:22

Signed-off-by: Hong Zhiguo <honkiko< at >gmail.com>
---
 net/bridge/br_netlink.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index b96e02e..8e3abf5 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
< at >< at > -352,17 +352,14 < at >< at > static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
 /* Change state and parameters on port. */
 int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
 {
-struct ifinfomsg *ifm;
 struct nlattr *protinfo;
 struct nlattr *afspec;
 struct net_bridge_port *p;
 struct nlattr *tb[IFLA_BRPORT_MAX + 1];
 int err = 0;
 
-ifm = nlmsg_data(nlh);
-
-protinfo = nlmsg_find_attr(nlh, sizeof(*ifm), IFLA_PROTINFO);
-afspec = nlmsg_find_attr(nlh, sizeof(*ifm), IFLA_AF_SPEC);
+protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_PROTINFO);
+afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
 if (!protinfo && !afspec)
 return 0;
 
< at >< at > -411,14 +40

[PATCH] bridge: fix crash when set mac address of brinterface

Hong Zhiguo — 2013-03-23T12:27:50

When I tried to set mac address of a bridge interface to a mac
address which already learned on this bridge, I got system hang.

The cause is straight forward: function br_fdb_change_mac_address
calls fdb_insert with NULL source nbp. Then an fdb lookup is
performed. If an fdb entry is found and it's local, it's OK. But
if it's not local, source is dereferenced for printk without NULL
check.

Signed-off-by: Hong Zhiguo <honkiko< at >gmail.com>
---
 net/bridge/br_fdb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 10b47d4..c581f12 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
< at >< at > -421,7 +421,7 < at >< at > static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
 return 0;
 br_warn(br, "adding interface %s with same address "
        "as a received packet\n",
-       source->dev->name);
+       source ? source->dev->name : br->dev->name);
 fdb_delete(br, fdb);
 }

[PATCH net-next] bridge: avoid br_ifinfo_notify whennothing changed

Hong Zhiguo — 2013-03-23T05:14:13

When neither IFF_BRIDGE_PORT or IFF_BRIDGE_PORT is set,
and afspec == NULL but  protinfo != NULL, we run into
"if (err == 0) br_ifinfo_notify(RTM_NEWLINK, p);" with
random value in ret.

Signed-off-by: Hong Zhiguo <honkiko< at >gmail.com>
---
 net/bridge/br_netlink.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 84c3b7d..b96e02e 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
< at >< at > -357,7 +357,7 < at >< at > int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
 struct nlattr *afspec;
 struct net_bridge_port *p;
 struct nlattr *tb[IFLA_BRPORT_MAX + 1];
-int err;
+int err = 0;
 
 ifm = nlmsg_data(nlh);
 
< at >< at > -370,7 +370,7 < at >< at > int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
 /* We want to accept dev as bridge itself if the AF_SPEC
  * is set to see if someone is setting vlan info on the brigde
  */
-if (!p && ((dev->priv_flags & IFF_EBRIDGE) && !afspec))
+if (!p && !afspec)
 return -EINVAL;

[PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener queries

Satya Narayana — 2013-03-20T16:26:31

Hello,

I am using 2.6.39.4 kernel for MLD snooping, in net/bridge/br_multicast.c
file,

we observed the check for tranoisent flag in the group address.

 That mean with out this flag set the group address will be droped.

 My doubt is why MLD is restricted with T (transient) flag, we can't use
with out T flag multicast group address.

 Looking forward for you replay, Thank you in advance.


Regards,

Satya

[PATCH v2] net: add ETH_P_802_3_MIN

Simon Horman — 2013-03-28T04:38:25

Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
an 802.3 frame. Frames with a lower value in the ethernet type field
are Ethernet II.

Also update all the users of this value that David Miller and
I could find to use the new constant.

Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
should be >= not >.

As suggested by Jesse Gross.

Compile tested only.

Cc: David Miller <davem< at >davemloft.net>
Cc: Jesse Gross <jesse< at >nicira.com>
Cc: Karsten Keil <isdn< at >linux-pingi.de>
Cc: John W. Linville <linville< at >tuxdriver.com>
Cc: Johannes Berg <johannes< at >sipsolutions.net>
Cc: Bart De Schuymer <bart.de.schuymer< at >pandora.be>
Cc: Stephen Hemminger <stephen< at >networkplumber.org>
Cc: Patrick McHardy <kaber< at >trash.net>
Cc: Marcel Holtmann <marcel< at >holtmann.org>
Cc: Gustavo Padovan <gustavo< at >padovan.org>
Cc: Johan Hedberg <johan.hedberg< at >gmail.com>
Cc: linux-bluetooth< at >vger.kernel.org
Cc: netfilter-devel< at >vger.kernel.org
Cc: bridge< at >lists.linux-foundation.org
Cc: linux-wireless< at >vger.kernel.org
Cc: linux139

[PATCH] bridge: netfilter: use PTR_RET instead of IS_ERR +PTR_ERR

Silviu-Mihai Popescu — 2013-03-12T18:11:33

This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
readability.

Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990< at >gmail.com>
---
 net/bridge/netfilter/ebtable_broute.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/bridge/netfilter/ebtable_broute.c b/net/bridge/netfilter/ebtable_broute.c
index 40d8258..70f656c 100644
--- a/net/bridge/netfilter/ebtable_broute.c
+++ b/net/bridge/netfilter/ebtable_broute.c
< at >< at > -64,9 +64,7 < at >< at > static int ebt_broute(struct sk_buff *skb)
 static int __net_init broute_net_init(struct net *net)
 {
 net->xt.broute_table = ebt_register_table(net, &broute_table);
-if (IS_ERR(net->xt.broute_table))
-return PTR_ERR(net->xt.broute_table);
-return 0;
+return PTR_RET(net->xt.broute_table);
 }
 
 static void __net_exit broute_net_exit(struct net *net)