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:	Tue, 15 Nov 2011 21:02:24 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Andy Gospodarek <andy@...yhouse.net>
CC:	Veaceslav Falico <vfalico@...hat.com>, netdev@...r.kernel.org,
	Jay Vosburgh <fubar@...ibm.com>
Subject: Re: [PATCH] bonding: Don't allow mode change via sysfs with slaves
 present

Le 15/11/2011 20:35, Andy Gospodarek a écrit :
> On Tue, Nov 15, 2011 at 08:24:29PM +0100, Nicolas de Pesloüan wrote:
>> Le 15/11/2011 18:00, Andy Gospodarek a écrit :
>>> On Tue, Nov 15, 2011 at 05:44:42PM +0100, Veaceslav Falico wrote:
>>>> When changing mode via bonding's sysfs, the slaves are not initialized
>>>> correctly. Forbid to change modes with slaves present to ensure that every
>>>> slave is initialized correctly via bond_enslave().
>>>>
>>>> Signed-off-by: Veaceslav Falico<vfalico@...hat.com>
>>>
>>> Looks good.  This behavior forces someone who wants to change to mode to
>>> go through steps that are almost as destructive as when module options
>>> are used to configure the mode.  I do not see a problem with this.
>>
>> Except the fact that is enforce one more constraint on the exact order
>> one should write into sysfs to setup a bonding interface. We already have
>> many such constraints and probably don't need more.
>>
>> Currently, it is possible to enslave slaves before selecting the mode.
>> The ifenslave-2.6 package from Debian currently enslave slaves before
>> setting the mode and would break with this change.
>>
>
> Our testing indicates that 802.3ad mode bonding will not work unless the
> devices are enslaved after the mode is set.  Does this mean that no one
> using Debian is using 802.2ad mode or are they just not reporting it?

I don't know. Possibly, they setup the bonding by hand, instead of relying on the bonding extensions 
of /etc/network/interfaces provided by the ifenslave-2.6 package.

Having a look at popularity for the package (http://qa.debian.org/popcon.php?package=ifenslave-2.6), 
it is obviously not the most popular one, but...

To try and fix the problem you noticed, if might be desirable to assert carrier off then on for all 
slaves when entering 802.3ad mode.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ