netdev - Re: Bug#697357: bridging broken over bond interfaces

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

Date:	Tue, 22 Jan 2013 21:20:44 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	netdev <netdev@...r.kernel.org>, Bastian Blank <waldi@...ian.org>,
	697357@...s.debian.org, Peter Palfrader <weasel@...ian.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>, wferi@...f.hu
Subject: Re: Bug#697357: bridging broken over bond interfaces

Ben Hutchings <ben@...adent.org.uk> writes:

> Forwarding this to netdev since the bug is still present in Linux 3.7.1.
> For those joining us, this thread is archive at
> <http://bugs.debian.org/697357>.

Please forgive me for eliding the previous discussion; I think I hit the
same or a very similar problem in the same setup, but without the KVM or
guest parts (but I could reproduce this in a pretty bare KVM guest with
a virtio network device).  My interface configuration (hopefully
comprehensible without familiarity with Debian):

# this is a bare bond interface named after the native VLAN (no .1q!)
auto vlan894
iface vlan894 inet manual
	bond_mode	active-backup
	bond_slaves	eth0
	bond_miimon	100
	bond_updelay	4000

# this bridge has a static IPv4 address and contains the above bond
auto br894
iface br894 inet static
	bridge_ports	vlan894
	bridge_stp	off
	bridge_fd	0
	address		x.y.z.w
	netmask		255.255.255.0
	gateway		x.y.z.g

Actually, I want ARP monitoring for the bond, but if I leave out either
the miimon *or* the updelay configuration, the machine stops responding
to solicited-node multicast packages (neighbor solicitations) thus
becoming unreachable via its autoconfigured global IPv6 address.  That
is, until I put eth0 into promiscuous mode!  And really, with the above
(working) config dmesg says:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: Setting up delay to 4000.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: enslaving eth0 as a backup interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): vlan894: link is not ready
bonding: vlan894: link status definitely up for interface eth0, 4294967295 Mbps full duplex.
bonding: vlan894: making interface eth0 the new active one.
device eth0 entered promiscuous mode
bonding: vlan894: first active interface up!
IPv6: ADDRCONF(NETDEV_CHANGE): vlan894: link becomes ready
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

(although ip link does not list any promiscuous interfaces).  On the
other hand, if I don't configure eg. bond_updelay:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: making interface eth0 the new active one.
bonding: vlan894: first active interface up!
bonding: vlan894: enslaving eth0 as an active interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

ie. promiscuous mode isn't propageted to eth0 and the global IPv6
address of the machine does not respond to ping6 until tcpdump -i eth0
or ip link set eth0 promisc on.  Meanwhile in all cases:

# ip maddr show dev br894
5:	br894
	link  33:33:00:00:00:01
	link  01:00:5e:00:00:01
	link  33:33:ff:02:00:07
	inet  224.0.0.1
	inet6 ff02::1:ff02:7 users 2
	inet6 ff02::1

This happens with the current 3.7.3-1~experimental.1 amd64 kernel under
Debian wheezy (besides the current 3.2 wheezy kernel).
-- 
Thanks for your time,
Feri.
--
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