netdev - Re: unresponsive vlan on top of bond with fail_over

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: <29107.1350002028@death.nxdomain>
Date:	Thu, 11 Oct 2012 17:33:48 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Michal Kubecek <mkubecek@...e.cz>
cc:	netdev@...r.kernel.org, Andy Gospodarek <andy@...yhouse.net>
Subject: Re: unresponsive vlan on top of bond with fail_over_mac=active

Michal Kubecek <mkubecek@...e.cz> wrote:

>On Wed, Oct 10, 2012 at 08:34:31PM -0700, Jay Vosburgh wrote:
>> Michal Kubecek <mkubecek@...e.cz> wrote:
>> 	What network device are they using that requires fail_over_mac
>> to be set to active?
>
>I would have to ask for exact configuration, all I know for sure is that
>the problem was reported for s390x (S390-64) architecture. I reproduced
>it with VMware Workstation virtual devices which emulate Intel e1000.

	Have you tried the "follow" setting to fail_over_mac?

	I looked into this very topic (VLAN address propagation on s390)
earlier this year.  The eventual solution for that case was to use the
"follow" fail_over_mac option, which resolved the problem for the OSA
device (qeth).

	I did submit a patch to do MAC address propagation to VLANs, but
then withdrew it after I figured out that "follow" would also resolve
the problem without code changes.

http://patchwork.ozlabs.org/patch/153551/

>> 	I tested some of this out earlier this year, and I don't recall
>> having problems (although I'm not sure I did this exact test).  The
>> dev_uc_add() logic (in __dev_set_rx_mode) would put the underlying
>> device into promiscuous mode if the hardware didn't support multiple
>> unicast MAC addresses. dev_uc_add() was invoked by vlan_sync_address(),
>> which is called by the vlan NETDEV_CHANGEADDR notifier callback.
>
>Yes, this part works fine, I checked uc list with live crash session.
>But as bonding driver doesn't set its ndo_set_rx_mode method, the
>iformation about second MAC address doesn't propagate down to the
>slaves.

	What kernel are you looking at?  In current mainline, bonding
does have bond_set_multicast_list as ndo_set_rx_mode, although it
doesn't propagate unicast address information, only multicast.  I
believe this has been the case for a long time.

>> 	Bonding does propagate promisc to its slaves, but (as you point
>> out) not the uc lists; is the hardware in question something that
>> supports multiple unicast addresses (IFF_UNICAST_FLT)?  The device I
>> tested with does not support IFF_UNICAST_FLT, and (as I recall) would
>> end up in promisc mode.
>
>My tests were done with (emulated) e1000 which supports unicast
>filtering (up to 14 addresses, according to what I've seen in the
>driver). I'm not sure about the devices on s390x.

	-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