netdev - Re: [patch net-next V2] bond: have random dev address by default instead of zeroes

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21365.1359136387@death.nxdomain>
Date:	Fri, 25 Jan 2013 09:53:07 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Jiri Pirko <jiri@...nulli.us>
cc:	netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net,
	stephen@...workplumber.org, psimerda@...hat.com, dcbw@...hat.com
Subject: Re: [patch net-next V2] bond: have random dev address by default instead of zeroes

Jiri Pirko <jiri@...nulli.us> wrote:

>Fri, Jan 25, 2013 at 07:37:13AM CET, jiri@...nulli.us wrote:
>>Fri, Jan 25, 2013 at 02:35:01AM CET, fubar@...ibm.com wrote:
>>>Jiri Pirko <jiri@...nulli.us> wrote:
>>>
>>>>Makes more sense to have randomly generated address by default than to
>>>>have all zeroes. It also allows user to for example put the bond into
>>>>bridge without need to have any slaves in it.
>>>>
>>>>Also note that this changes only behaviour of bonds with no slaves. Once
>>>>the first slave device is enslaved, its address will be used (no change
>>>>here).
>
>
>Also, this is not entirely true now. Example:
>
>eth1 has 52:54:00:b8:30:0b
>
># ip link add bondx address 22:33:44:55:66:77 type bond
># ip link set eth1 master bondx
>
>Now both bondx and eth1 has 22:33:44:55:66:77
>
>Shouldn't both have 52:54:00:b8:30:0b ?

	This is the way bonding has worked for as long as I can recall.
The MAC of the first slave is assigned to the master, unless the bond
has had its MAC manually set to something prior to the first slave being
added.  If the bond's MAC has been set manually, then that MAC is used
instead of the first slave's MAC.

	Your patch doesn't appear to change that behavior, but it does
substitute a random MAC in place of the all zeroes MAC used previously
(and tests a flag to determine if the MAC has been manually set instead
of checking for the all zeroes MAC).

	I know of customers that rely on this behavior to explicitly set
the MAC of the bond (for filtering or accounting purposes).  It probably
should be documented more clearly, but I don't think it should be
changed.

	-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