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]

Date:	Fri, 25 Jan 2013 14:42:01 -0500 (EST)
From:	Pavel Simerda <psimerda@...hat.com>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net,
	stephen@...workplumber.org, dcbw@...hat.com,
	Jiri Pirko <jiri@...nulli.us>
Subject: Re: [patch net-next V2] bond: have random dev address by default
 instead of zeroes

----- Original Message -----
> From: "Jay Vosburgh" <fubar@...ibm.com>
> To: "Pavel Simerda" <psimerda@...hat.com>
> Cc: netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net, stephen@...workplumber.org, dcbw@...hat.com,
> "Jiri Pirko" <jiri@...nulli.us>
> Sent: Friday, January 25, 2013 7:31:32 PM
> Subject: Re: [patch net-next V2] bond: have random dev address by default instead of zeroes
> 
> Pavel Simerda <psimerda@...hat.com> wrote:
> 
> >----- Original Message -----
> >> From: "Jay Vosburgh" <fubar@...ibm.com>
> >> but I don't think it should be changed.
> >
> >Just a short question. Is there any reason for bonding interfaces to
> >behave differently from bridging interfaces in this respect?
> 
> 	To clarify, what I don't think should change is that a manually
> set MAC on the bonding master should override the automatic copy of
> the
> first slave's MAC to the bonding master.  The fail_over_mac active
> and
> follow settings are an exception to this, but those are special cases
> for unusual network hardware.
> 
> 	As for the random MAC vs. zero MAC, I've always thought that the
> all zero MAC was a clear indicator that the device (the bonding
> master
> in this case) was not in a usable state (in the sense that it could
> not
> send or receive actual traffic).  It's not a really big deal, though,
> so

Thanks for clarification.
> if the trend these days is for everything to have a MAC all the time,
> that's fine, as long as doing so doesn't break anything.
> 
> 	I think the patch under discussion should be fine with the
> addition of the last notifier call previously discussed.  Some
> documentation updates would be nice, too.
> 
> 	-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