netdev - Re: bonding: why zero out bond_dev->dev

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 for Android: free password hash cracker in your pocket

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

Message-ID: <26676.1345670410@death.nxdomain>
Date:	Wed, 22 Aug 2012 14:20:10 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Chris Friesen <chris.friesen@...band.com>
cc:	Andy Gospodarek <andy@...yhouse.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: bonding: why zero out bond_dev->dev_addr when last slave removed?

Chris Friesen <chris.friesen@...band.com> wrote:
[...]
>I was wondering about the rationale for zeroing out bond_dev->dev_addr
>when the last slave is removed from the bond.
>
>Assuming bond0 is currently using the mac address of eth0 then doing
>
>ifenslave -d bond0 eth0
>ifenslave -d bond0 eth1
>ifenslave bond0 eth1
>ifenslave bond0 eth0
>
>ends up changing the MAC address of the bond link. Given that the bond
>itself stays up during this time, why don't we let the bond device keep
>it's previous MAC address (at least if fail_over_mac is zero)?
>
>Is this to account for the case where we move the bond to totally
>different devices such that the old MAC no longer belongs to one of the
>slaves but instead belongs to a NIC outside the bond?

	More or less.  When the last slave is removed from the bond,
several properties of the bond are reset to an initial state, one of
which is that the bond's MAC is reset to all zeroes.

	If fail_over_mac is set to "active," then the bond must use the
MAC of one of its slaves, as the implication is that the slaves cannot
or should not change their MAC addresses.  In this case, I believe the
bond's MAC will be set to the first active slave's MAC, so holding over
the bond's MAC makes no practical difference.

	For fail_over_mac=follow, if the bond kept its MAC, then it
would be possible for both slaves to end up with the same MAC (because
the follow logic will set the first slave to the bond's MAC when it is
made active, and the second slave will keep its MAC after enslavement,
and those could be the same MAC if the second slave is the one the bond
originally got its MAC from).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html