Bug 9545 - Cannot bring up a bridge interface without a MAC address set
Cannot bring up a bridge interface without a MAC address set
Status: CLOSED CODE_FIX
Product: Networking
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 9243
  Show dependency treegraph
 
Reported: 2007-12-11 11:04 UTC by Daniel Berrange
Modified: 2007-12-17 16:02 UTC (History)
0 users

See Also:
Kernel Version: 2.6.24-0.81.rc4.git7.fc9
Tree: Fedora
Regression: ---


Attachments

Description Daniel Berrange 2007-12-11 11:04:54 UTC
Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
Distribution: Fedora 9 rawhide
Hardware Environment: Intel(R) Core(TM)2 Duo CPU     E6850, x86_64
Software Environment:  2.6.24-0.81.rc4.git7.fc9 #1 SMP  x86_64 GNU/Linux
Problem Description:
It is not possible to bring up a bridge interface unless one first assigns a MAC address to it. This is a regression from earlier kernels where one could always bring up a bridge device immediately after creating it. The bridge should not require a MAC address because it is not going to be configured with any IP addr - in my scenario I merely wish to use it to connect a number of 'tap' devices associated with KVM guests.

Steps to reproduce:
# brctl addbr demobr
# ifconfig demobr up
SIOCSIFFLAGS: Invalid argument

It is failing on the ioctl to bring up the interface

ioctl(4, SIOCGIFFLAGS, {ifr_name="demobr", ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0x7fff38a6f180)  = -1 EINVAL (Invalid argument)


The following Fedora kernel BZ has the original problem report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=390991

The problem appears to have been introduced by this patch:

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);



Which rejects MAC addresses with all 0s

Herbert Xu tells me...

"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."
Comment 1 Anonymous Emailer 2007-12-11 13:27:27 UTC
Reply-To: akpm@linux-foundation.org


(please respond via emailed reply-to-all, not via the bugzilla web
interface).

On Tue, 11 Dec 2007 11:04:55 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9545
> 
>            Summary: Cannot bring up a bridge interface without a MAC address
>                     set
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.24-0.81.rc4.git7.fc9
>           Platform: All
>         OS/Version: Linux
>               Tree: Fedora
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: acme@ghostprotocols.net
>         ReportedBy: berrange@redhat.com
> 
> 
> Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
> Distribution: Fedora 9 rawhide
> Hardware Environment: Intel(R) Core(TM)2 Duo CPU     E6850, x86_64
> Software Environment:  2.6.24-0.81.rc4.git7.fc9 #1 SMP  x86_64 GNU/Linux
> Problem Description:
> It is not possible to bring up a bridge interface unless one first assigns a
> MAC address to it. This is a regression from earlier kernels where one could
> always bring up a bridge device immediately after creating it. The bridge
> should not require a MAC address because it is not going to be configured with
> any IP addr - in my scenario I merely wish to use it to connect a number of
> 'tap' devices associated with KVM guests.
> 
> Steps to reproduce:
> # brctl addbr demobr
> # ifconfig demobr up
> SIOCSIFFLAGS: Invalid argument
> 
> It is failing on the ioctl to bring up the interface
> 
> ioctl(4, SIOCGIFFLAGS, {ifr_name="demobr",
> ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
> ioctl(4, SIOCSIFFLAGS, 0x7fff38a6f180)  = -1 EINVAL (Invalid argument)
> 
> 
> The following Fedora kernel BZ has the original problem report:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=390991
> 
> The problem appears to have been introduced by this patch:
> 
> 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);
> 
> 
> 
> Which rejects MAC addresses with all 0s
> 
> Herbert Xu tells me...
> 
> "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."
> 

Rafael, another for the regression list please.

Comment 2 Stephen Hemminger 2007-12-11 14:55:09 UTC
On Tue, 11 Dec 2007 13:26:14 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> (please respond via emailed reply-to-all, not via the bugzilla web
> interface).
> 
> On Tue, 11 Dec 2007 11:04:55 -0800 (PST)
> bugme-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=9545
> > 
> >            Summary: Cannot bring up a bridge interface without a MAC address
> >                     set
> >            Product: Networking
> >            Version: 2.5
> >      KernelVersion: 2.6.24-0.81.rc4.git7.fc9
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Fedora
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Other
> >         AssignedTo: acme@ghostprotocols.net
> >         ReportedBy: berrange@redhat.com
> > 
> > 
> > Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
> > Distribution: Fedora 9 rawhide
> > Hardware Environment: Intel(R) Core(TM)2 Duo CPU     E6850, x86_64
> > Software Environment:  2.6.24-0.81.rc4.git7.fc9 #1 SMP  x86_64 GNU/Linux
> > Problem Description:
> > It is not possible to bring up a bridge interface unless one first assigns a
> > MAC address to it. This is a regression from earlier kernels where one could
> > always bring up a bridge device immediately after creating it. The bridge
> > should not require a MAC address because it is not going to be configured with
> > any IP addr - in my scenario I merely wish to use it to connect a number of
> > 'tap' devices associated with KVM guests.
> > 
> > Steps to reproduce:
> > # brctl addbr demobr
> > # ifconfig demobr up
> > SIOCSIFFLAGS: Invalid argument

The tap devices have to have addresses don't they. So bringing up an empty
bridge is meaningless. If you just add the device first then it will work.

Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.
The problem is that when device is brought up it propogates events up to
other layers and applications, these layers will then query and see a bogus
address.

Comment 3 Anonymous Emailer 2007-12-11 15:00:04 UTC
Reply-To: akpm@linux-foundation.org

On Tue, 11 Dec 2007 14:52:43 -0800
Stephen Hemminger <shemminger@linux-foundation.org> wrote:

> On Tue, 11 Dec 2007 13:26:14 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > 
> > (please respond via emailed reply-to-all, not via the bugzilla web
> > interface).
> > 
> > On Tue, 11 Dec 2007 11:04:55 -0800 (PST)
> > bugme-daemon@bugzilla.kernel.org wrote:
> > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9545
> > > 
> > >            Summary: Cannot bring up a bridge interface without a MAC address
> > >                     set
> > >            Product: Networking
> > >            Version: 2.5
> > >      KernelVersion: 2.6.24-0.81.rc4.git7.fc9
> > >           Platform: All
> > >         OS/Version: Linux
> > >               Tree: Fedora
> > >             Status: NEW
> > >           Severity: normal
> > >           Priority: P1
> > >          Component: Other
> > >         AssignedTo: acme@ghostprotocols.net
> > >         ReportedBy: berrange@redhat.com
> > > 
> > > 
> > > Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
> > > Distribution: Fedora 9 rawhide
> > > Hardware Environment: Intel(R) Core(TM)2 Duo CPU     E6850, x86_64
> > > Software Environment:  2.6.24-0.81.rc4.git7.fc9 #1 SMP  x86_64 GNU/Linux
> > > Problem Description:
> > > It is not possible to bring up a bridge interface unless one first assigns a
> > > MAC address to it. This is a regression from earlier kernels where one could
> > > always bring up a bridge device immediately after creating it. The bridge
> > > should not require a MAC address because it is not going to be configured with
> > > any IP addr - in my scenario I merely wish to use it to connect a number of
> > > 'tap' devices associated with KVM guests.
> > > 
> > > Steps to reproduce:
> > > # brctl addbr demobr
> > > # ifconfig demobr up
> > > SIOCSIFFLAGS: Invalid argument
> 
> The tap devices have to have addresses don't they. So bringing up an empty
> bridge is meaningless. If you just add the device first then it will work.
> 
> Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.
> The problem is that when device is brought up it propogates events up to
> other layers and applications, these layers will then query and see a bogus
> address.
> 

If the fix to make bridge compatible with 2.6.23 behaviour isn't too
gruesome then I'd have thought it'd be worth doing it?

Comment 4 Rafael J. Wysocki 2007-12-11 16:38:13 UTC
Patch is available: http://marc.info/?l=linux-netdev&m=119741724408852&w=2
Comment 5 Herbert Xu 2007-12-11 17:51:47 UTC
On Tue, Dec 11, 2007 at 02:52:43PM -0800, Stephen Hemminger wrote:
>
> The tap devices have to have addresses don't they. So bringing up an empty
> bridge is meaningless. If you just add the device first then it will work.

Actually bringing up a bridge with no constituents is useful for
a bridge that's made up of only virtual interfaces.  Since each
vritual interface may be created or destroyed at run-time it'd
be quite awkward to check every time to see if that's the last
or first and act differently on the bridge.

More importantly constiuents can be added to and removed from a
bridge without taking it down.

> Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.

Well this stops FC8 working with Xen so for that it's a showstopper :)

> The problem is that when device is brought up it propogates events up to
> other layers and applications, these layers will then query and see a bogus
> address.

What exactly would it break for this scenario though?

Cheersk,
Comment 6 Stephen Hemminger 2007-12-11 21:39:02 UTC
On Wed, 12 Dec 2007 09:51:05 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Tue, Dec 11, 2007 at 02:52:43PM -0800, Stephen Hemminger wrote:
> >
> > The tap devices have to have addresses don't they. So bringing up an empty
> > bridge is meaningless. If you just add the device first then it will work.
> 
> Actually bringing up a bridge with no constituents is useful for
> a bridge that's made up of only virtual interfaces.  Since each
> vritual interface may be created or destroyed at run-time it'd
> be quite awkward to check every time to see if that's the last
> or first and act differently on the bridge.
> 
> More importantly constiuents can be added to and removed from a
> bridge without taking it down.
> 
> > Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.
> 
> Well this stops FC8 working with Xen so for that it's a showstopper :)
> 
> > The problem is that when device is brought up it propogates events up to
> > other layers and applications, these layers will then query and see a bogus
> > address.
> 
> What exactly would it break for this scenario though?

Well with earlier kernels, ipv6 and others would see an invalid address (all zeros).
That could be a problem if some netlink watching program or udev script
propagated that value into a database or management interface. But now
using a random value, that won't happen.


Comment 7 Rafael J. Wysocki 2007-12-17 16:01:51 UTC
Fixed by:

commit 3ae412544cde6d987e0e48778bd87bc96a5749df
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date:   Sun Dec 16 13:35:51 2007 -0800

    [BRIDGE]: Assign random address.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3ae412544cde6d987e0e48778bd87bc96a5749df

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