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. Braun
Notify 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@xxxxxxxxxxxxx>
--- a/net/bridge/br_fdb.c 2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_fdb.c 2013-04-15 11:23:55.941166319 +0200
@@ -408,6 +408,7 @@ static int fdb_insert(struct net_bridge
{
struct hlist_head *head = &br->hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
if (!is_valid_ether_addr(addr))
return -EINVAL;
@@ -471,8 +472,12 @@ void br_fdb_update(struct net_bridge *br
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb->dst;
fdb->dst = source;
fdb->updated = jiffies;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(&br->hash_lock);
