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

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

[michael-dev]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

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

[-- Attachment #2: 999-make-bridge-notify-switched-port.diff --]
[-- Type: text/plain, Size: 1213 bytes --]

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@fami-braun.de>

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