linux-kernel - [PATCH net] bonding: emit event when bonding changes MAC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <5e96194e81e0540ebd35cf0bb1b407aa15a20613.1332910907.git.wpan@redhat.com>
Date:	Wed, 28 Mar 2012 13:18:24 +0800
From:	Weiping Pan <wpan@...hat.com>
To:	netdev@...r.kernel.org
Cc:	fubar@...ibm.com, andy@...yhouse.net, lwang@...hat.com,
	linux-kernel@...r.kernel.org, Weiping Pan <wpan@...hat.com>
Subject: [PATCH net] bonding: emit event when bonding changes MAC

When a bonding device is configured with fail_over_mac=active,
we expect to see the MAC address of the new active slave as the source MAC
address after failover. But we see that the source MAC address is the MAC
address of previous active slave.

Emit NETDEV_CHANGEADDR event when bonding changes its MAC address, in order
to let arp_netdev_event flush neighbour cache and route cache.

How to reproduce this bug ?

                       -----------hostB----------------
hostA ----- switch ---|-- eth0--bond0(192.168.100.2/24)|
(192.168.100.1/24  \--|-- eth1-/                       |
                       --------------------------------

1 on hostB,
modprobe bonding mode=1 miimon=500 fail_over_mac=active downdelay=1000
num_grat_arp=1
ifconfig bond0 192.168.100.2/24 up
ifenslave bond0 eth0
ifenslave bond0 eth1

then eth0 is the active slave, and MAC of bond0 is MAC of eth0.

2 on hostA, ping 192.168.100.2

3 on hostB,
tcpdump -i bond0 -p icmp -XXX
you will see bond0 uses MAC of eth0 as source MAC in icmp reply.

4 on hostB,
ifconfig eth0 down
tcpdump -i bond0 -p icmp -XXX (just keep it running in step 3)
you will see first bond0 uses MAC of eth1 as source MAC in icmp
reply, then it will use MAC of eth0 as source MAC.

Signed-off-by: Weiping Pan <wpan@...hat.com>
---
 drivers/net/bonding/bond_main.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b920d82..a20b585 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -892,9 +892,15 @@ static void bond_do_fail_over_mac(struct bonding *bond,
 
 	switch (bond->params.fail_over_mac) {
 	case BOND_FOM_ACTIVE:
-		if (new_active)
+		if (new_active) {
 			memcpy(bond->dev->dev_addr,  new_active->dev->dev_addr,
 			       new_active->dev->addr_len);
+			write_unlock_bh(&bond->curr_slave_lock);
+			read_unlock(&bond->lock);
+			call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev);
+			read_lock(&bond->lock);
+			write_lock_bh(&bond->curr_slave_lock);
+		}
 		break;
 	case BOND_FOM_FOLLOW:
 		/*
-- 
1.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/