Bug 9545
| Summary: | Cannot bring up a bridge interface without a MAC address set | ||
|---|---|---|---|
| Product: | Networking | Reporter: | Daniel Berrange (berrange) |
| Component: | Other | Assignee: | Rafael J. Wysocki (rjwysocki) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.24-0.81.rc4.git7.fc9 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 9243 | ||
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. 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. 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? Patch is available: http://marc.info/?l=linux-netdev&m=119741724408852&w=2 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, 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. 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 |
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."