[PATCH] Notify userspace about bridge learning MAC on new port

[michael-dev]

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@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);