netdev - Bonding driver problem

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

Message-ID: <20130225141008.00004621@unknown>
Date:	Mon, 25 Feb 2013 14:10:08 -0800
From:	Greg Rose <gregory.v.rose@...el.com>
To:	<netdev@...r.kernel.org>, <jiri@...nulli.us>
CC:	<sibai.li@...el.com>
Subject: Bonding driver problem

We're having some problems with the following commit:

commit 409cc1f8a4149c26bbb8e5d3bacb36541ad371e2
Author: Jiri Pirko <jiri@...nulli.us>
Date:   Wed Jan 30 11:08:11 2013 +0100

    bond: have random dev address by default instead of zeroes

    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, fix dev_assign_type values on the way.

    Reported-by: Pavel Šimerda <psimerda@...hat.com>
    Signed-off-by: Jiri Pirko <jiri@...nulli.us>
    Signed-off-by: Jay Vosburgh <fubar@...ibm.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

According to our tester, Sibai, before the patch, the mac of bonding
device is assigned by default as zero when it has no slave. Once the
first slave is enslaved, the bonding device takes the mac of first
slave, then passes this mac to all slaves. 

But with this patch, the mac of the bonding interface is assigned a
random mac, and when the slave device is enslaved, the bonding device
keeps taking the mac of the slave it last enslaved. And former enslaved
slaves keep reverting to their original mac.  So for  mode 1, since the
first slave is the active one, the rest of the slaves are the backup,
because the mac of bonding is different than the first slave, so the
bonding device cannot receive packets.

When we tried test build that reverted this patch the issue she was
seeing went away and the bonding worked the she was accustomed to.

This may be deliberate and we may have to change our test procedures
but we wanted to make sure.

The specific use case is to use a two virtual functions each from a
different physical function port to create fail over bonding.

Thanks,

- Greg Rose
Networking Division
Intel Corp.
--
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