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: <20121011103757.GA13873@unicorn.suse.cz>
Date:	Thu, 11 Oct 2012 12:37:58 +0200
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	netdev@...r.kernel.org, Andy Gospodarek <andy@...yhouse.net>
Subject: Re: unresponsive vlan on top of bond with fail_over_mac=active

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.

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

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

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