Bug 390991 - network address validation fails when bringing up bridge devices
network address validation fails when bringing up bridge devices
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: 393051 412251 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-11-19 14:52 EST by Jeremy Katz
Modified: 2008-04-27 00:24 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-27 00:24:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of libvirtd when doing net-start (8.18 KB, text/plain)
2007-11-19 14:53 EST, Jeremy Katz
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 9545 None None None Never

  None (edit)
Description Jeremy Katz 2007-11-19 14:52:35 EST
With 2.6.24-rc, bringing up the virtual network bridge gives
[root@aglarond ~]# virsh -c qemu:///system net-start defaultlibvir: QEMU error :
failed to bring the bridge 'virbr0' up : Invalid argument
error: Failed to start network default
[root@aglarond ~]# dmesg |grep virbr0
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Comment 1 Jeremy Katz 2007-11-19 14:53:23 EST
Created attachment 263881 [details]
strace of libvirtd when doing net-start
Comment 2 Richard W.M. Jones 2007-11-20 10:27:45 EST
The call that fails is:

ioctl(7, SIOCGIFFLAGS, {ifr_name="virbr0",
ioctl(7, SIOCSIFFLAGS, 0x7fff7d52f660) = -1 EINVAL (Invalid argument)

which corresponds to the brSetInterfaceUp function in src/bridge.c
(the second ioctl fails):

    if (ioctl(ctl->fd, SIOCGIFFLAGS, &ifr) < 0)
        return errno;

    flags = up ? (ifr.ifr_flags | IFF_UP) : (ifr.ifr_flags & ~IFF_UP);

    if (ifr.ifr_flags != flags) {
        ifr.ifr_flags = flags;

        if (ioctl(ctl->fd, SIOCSIFFLAGS, &ifr) < 0)
            return errno;

Previous ioctls were successful, indicating that the bridge
exists, so I guess we're no longer allowed to set the IFF_UP
flag on bridges?
Comment 3 Daniel Berrange 2007-11-20 16:08:07 EST
*** Bug 393051 has been marked as a duplicate of this bug. ***
Comment 4 James Morris 2007-11-20 16:22:54 EST
Looks like this patch might have something to do with it:

commit bada339ba24dee9e143bfb42e1dc61f146619846
Author: Jeff Garzik <jgarzik@redhat.com>
Date:   Tue Oct 23 20:19:37 2007 -0700

    [NET]: Validate device addr prior to interface-up
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/core/dev.c b/net/core/dev.c
index 8726589..f861555 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1007,17 +1007,20 @@ int dev_open(struct net_device *dev)
         *      Call device private open method
        set_bit(__LINK_STATE_START, &dev->state);
-       if (dev->open) {
+       if (dev->validate_addr)
+               ret = dev->validate_addr(dev);

[ ... ]

That address validation check is failing, and it is calling eth_validate_addr()
on a bridge device.  Is this check supposed to be happening for a bridged device?

Comment 5 James Morris 2007-11-20 16:27:01 EST
The ethernet addr check is failing, as the hw addr of the bridge all zeros.
Comment 6 James Morris 2007-11-20 16:35:54 EST
Looks like you can't try and bring the bridge up without it being enslaved to a
device -- why do that anyway?
Comment 7 Daniel Berrange 2007-11-21 04:57:30 EST
The bridges used by libvirt are not connected to any physical device on the host
at all - they are merely for connecting together guests within a host. Each
bridge libvirt creates presents a local virtual network. We bring up the bridge
when the network is created, and then when guests are started, one of their
virtual (TAP) interfaces may be enslaved to the bridge. Co-ordinating to bring
up a bridge only when the first guest is started would be rather complicated &
error prone. We could just make up a random HW address for the bridge to get
past this new kernel check, but that's bit of a nasty hack.
Comment 8 Herbert Xu 2007-11-21 06:13:48 EST
Thanks for the excellent diagnosis!

This is clearly a bug in the upstream bridge device.  It should override the
default address validator so that when there are no devices attached that a zero
MAC address is allowed.

Please forward this bug to the upstream bugzilla.
Comment 9 Daniel Berrange 2007-12-05 11:18:39 EST
*** Bug 412251 has been marked as a duplicate of this bug. ***
Comment 10 Warren Togami 2007-12-05 16:16:28 EST
2.6.24-rc4-git2 upstream still affected.
Comment 11 Jeremy Katz 2007-12-14 10:46:21 EST
davej pulled in the patch which is pending for upstream to fix this.  Should be
in 2.6.24-0.103.rc5.git3.fc9

Note You need to log in before you can comment on or make changes to this bug.