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: <20130125180827.GA1821@minipsycho.orion>
Date:	Fri, 25 Jan 2013 19:08:27 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Jay Vosburgh <fubar@...ibm.com>
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

Fri, Jan 25, 2013 at 06:53:07PM CET, fubar@...ibm.com wrote:
>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).

Yeah, I know my patch is not changing this. I was just making sure it is
correct.

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