mac80211 "master" interface matches existant persistent network rules

Bug #183968 reported by Martin Pitt on 2008-01-18
368
This bug affects 1 person
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Critical
Scott James Remnant (Canonical)

Bug Description

Binary package hint: udev

My wifi interface is currently called "wlan0_rename", which indicates that the interface renaming was only half-done.

This box was installed with gutsy, and upgraded to hardy every couple of days.

-------------- snip ---------------
$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x1600 (tg3)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1c:23:14:1c:2a", NAME="eth0"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1b:77:d2:7f:26", NAME="eth1"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:24:a9:0c:60", NAME="eth2"
-------------- snip ---------------

$ dmesg |grep renamed
[ 36.268975] udev: renamed network interface wmaster0 to eth1

indeed I do have eth1 as well:

eth1 Link encap:UNSPEC Hardware Adresse 00-1B-77-D2-7F-26-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

but it's pretty useless.

SYMPTOMS:
This often shows up as an inability to use any wireless networks after suspending/hibernating and resuming. "ifconfig" will show an interface named "wlan0_rename" or similar.

WORKAROUND:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated correctly.

Note that this probably will change the names of your network interfaces, particularly your wireless ones. If you rely on them having particular identifiers (eth0, eth1, wlan0 etc) for the purposes of custom scripts, firewall rules or anything similar, you may need to update these settings after the file is regenerated.

FIX:
The intended fix for this bug is described at https://bugs.launchpad.net/ubuntu/+source/udev/+bug/183968/comments/9. It will eliminate the need for the workaround, but possibly only for new upgrades from Gutsy.

Hello. I have the same problem and I have seen lots of others on Ubuntuforums.org as well. I have tried fixing it by editing 70-persisting-net.rules but to no affect.

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:18:de:6f:5c:fe", NAME="eth1"

I have no problems using the interface as wlan0_rename though.

$ lsb_release -a
uname No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu hardy (development branch)
Release: 8.04
Codename: hardy
$ uname -a
Linux pc-thnov-ubuntu 2.6.24-4-generic #1 SMP Mon Jan 14 17:30:39 UTC 2008 i686 GNU/Linux

Gabriele Monti (psicus78) wrote :

I also experience a several seconds wait when:

udev: renamed network interface umaster0 eth1

then my wireless interface get named wlan0_renamed as well.

I have hardy updated from gutsy and iwl3945, dell inspiron e1505

Alex Mayorga (alex-mayorga) wrote :

I might be seeing this bug also on a Dell Inspiron 1501, my card is a Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) or so it says lspci.

Please let me know what I should provide for a fix or is there's a workaround because due to this my wireless interface is not functional any longer, it used to work rather fine.

I also see the bogus eth1 interface

eth1 Link encap:UNSPEC HWaddr AA-BB-CC-DD-EE-FF-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:3054 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3054 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:169188 (165.2 KB) TX bytes:169188 (165.2 KB)

wlan0_rename Link encap:Ethernet HWaddr AA-BB-CC-DD-EE-FF
          UP BROADCAST MULTICAST MTU:1492 Metric:1
          RX packets:586 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1135 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:182646 (178.3 KB) TX bytes:97538 (95.2 KB)

Alex Mayorga (alex-mayorga) wrote :

I found a workaround from Bug #180766

Rename /etc/udev/rules.d/70-persistent-net.rules to something else:
$ sudo mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.bak
Reboot
Wireless interface should be all merry again.

A wmaster0 bogus interface is still created, but at least wireless is functional again.

wlan0 Link encap:Ethernet HWaddr AA-BB-CC-DD-EE-FF
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wmaster0 Link encap:UNSPEC HWaddr AA-BB-CC-DD-EE-FF-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Here's the before:
$ tail /etc/udev/rules.d/70-persistent-net.rules.bak # See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:AA:BB:CC:DD:EE", NAME="eth0"

# PCI device 0x14e4:0x4311 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="AA:BB:CC:DD:EE:FF", NAME="eth1"

And here's the after:
$ tail /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:AA:BB:CC:DD:EE", ATTR{type}=="1", NAME="eth0"

# PCI device 0x14e4:0x4311 (b43-pci-bridge)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="AA:BB:CC:DD:EE:FF", ATTR{type}=="1", NAME="wlan0"

Hope it helps.

Changed in udev:
status: New → Confirmed
wvengen (wvengen) wrote :

I had the same problem after upgrading to Hardy; network-manager would work with it on boot, but after a resume-suspend cycle it didn't detect wifi anymore. Solved by following udev config modification mentioned at:
  http://wiki.debian.org/iwlwifi

Carlos Perelló Marín (carlos) wrote :

Confirmed, seems like is just a matter of remove the old ipw entry from /etc/udev/rules.d/70-persistent-net.rules

I still have two interfaces:

wlan0 Link encap:Ethernet HWaddr 00:1b:77:54:03:cb
          inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::21b:77ff:fe54:3cb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:7353 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6605 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9690264 (9.2 MB) TX bytes:894810 (873.8 KB)

wmaster0 Link encap:UNSPEC HWaddr 00-1B-77-54-03-CB-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

However, NetworkManager is now able to automatically mount my nfs entries in /etc/exports (see https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/208686 for more details). I think this is something that should be fixed in update-manager when upgrading from a previous distribution.

Changed in udev:
assignee: nobody → keybuk
importance: Undecided → Critical
milestone: none → ubuntu-8.04

The previous persistent network rules were generated _without_ ATTR{type}=="1" so would match any device with the right MAC address.

Changing to mac80211 for many devices in 8.04 means that these devices have gained an additional "wmaster0" control device that has the same MAC address.

Udev will attempt to rename both devices, usually with the wmaster0 winning the eth1 name since it's created first, and the wlan0 device getting "stuck" as wlan0_rename. This will generally hault the boot sequence for 30s as well.

New udev rules created have ATTR{type}=="1" so this only affects upgrades.

The correct solution is to fix /etc/udev/rules.d/70-persistent-net.rules on upgrade. Devices without ATTR{type} matching should be checked:
 - If a single device exists, and has a type, then we should add a match for that type (normal upgrade)
 - If multiple devices exist with types, then we should add ATTR{type}=="1" assuming that exists
 - If rules exist without an address match, they should be removed (this corrects a problem some people experienced because their udev didn't get upgraded to very late, so they had rules generated for the wmaster device that match everything)

We will not rename the device from ethX to wlanX; the entire point of these rules is to fix the names of devices.

New installations of Ubuntu, or newly added Wireless devices, will be named wlanX, while old devices on old installs will use the ethX naming convention.

Changed in udev:
status: Confirmed → In Progress
Josh (jharris0221) wrote :

Confirmed that deleting the old "# PCI device" entry from 70-persistant-net.rules and removing/reinserting the module will correct the problem. Seems to be an error that occurs when switching from ipw3945 to iwl3945 (I think this occured when upgrading Gutsy to Hardy).

Thanks wvengen for that link.

same here, it happened on upgrade from gutsy to hardy.

Martin Pitt (pitti) wrote :

For the record, the 70-persistant-net.rules diff in an automatic upgrade test between a gutsy->hardy upgrade (+++) and a fresh install (---):

-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="52:54:00:12:34:56", NAME="eth0"

I am having the same problems on my Lenovo X61. But there are further issues; Once the desktop has started the wireless does work.

However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only way to get it back is to restart the machine. Restarting X etc. does not do the trick.

Josh (jharris0221) wrote :

Ashkay,

This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as shown at http://wiki.debian.org/iwlwifi or as described above. It worked on my Lenovo T60p and fixed both the boot delay and the problem on resume from suspend.

description: updated
description: updated
David Mandala (davidm) wrote :

Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.

I believe this is critical to fix before release. My laptop worked correctly on gutsy and broke upon upgrade to hardy. This will cause a lot of people issues.

Steve Langasek (vorlon) wrote :

This bug is broadly confirmed and is already tracked as critical for the release, with work on resolving it already in progress. There is no need for further confirmations of the bug.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udev - 117-6

---------------
udev (117-6) hardy; urgency=low

  * Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
    where we can or at least add a useful comment where the user has written
    their own rule that's broken in the same way. LP: #183968.
  * Automatically comment out rules from 70-persistent-net.rules that would
    match any device.

 -- Scott James Remnant <email address hidden> Thu, 10 Apr 2008 23:49:41 +0100

Changed in udev:
status: In Progress → Fix Released
Mahdi (mahdi-hates-spam) wrote :

The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!

Gregory Oschwald (osch0001) wrote :

Did you follow the workaround in the bug description? The bug fix does not help people who upgraded to Hardy before the bug was fixed. Please try the following:

1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated correctly.

Mahdi (mahdi-hates-spam) wrote :

Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was fine on that update, then, after two small updates, it broke again! I thought the bug I subscribed at the time wasn't a duplicate.

I can't boot my laptop anymore. I had done the suggested workaround *before* the update. Today morning 10:00 am pacific I updated my machine and can't boot anymore. First, it gets stuck on "loading hardware drivers...", then when I force it to skip that it gets stuck starting the cups daemon.

What can I do? How can I boot my machine to command line at least? Any help will be greatly appreciated.

Ok I do have a clue. It seems to be the new kernel update "...-16" causing the problem. If I boot using the old kernel image "...-15" everything works ok!

On Fri, Apr 11, 2008 at 08:04:31PM -0000, Akshay Dua wrote:
> I can't boot my laptop anymore. I had done the suggested workaround
> *before* the update. Today morning 10:00 am pacific I updated my machine
> and can't boot anymore. First, it gets stuck on "loading hardware
> drivers...", then when I force it to skip that it gets stuck starting
> the cups daemon.

> What can I do? How can I boot my machine to command line at least? Any
> help will be greatly appreciated.

You're seeing bug #215833.

The best workaround is to boot to a previous kernel (or boot with rescue
mode from an install CD if necessary), then install the updated version of
the linux-ubuntu-modules package.

Thanks a bunch! I did figure that out, but really appreciate your quick reply.

Akshay

On Fri, Apr 11, 2008 at 1:15 PM, Steve Langasek
<email address hidden> wrote:
> On Fri, Apr 11, 2008 at 08:04:31PM -0000, Akshay Dua wrote:
> > I can't boot my laptop anymore. I had done the suggested workaround
> > *before* the update. Today morning 10:00 am pacific I updated my machine
> > and can't boot anymore. First, it gets stuck on "loading hardware
> > drivers...", then when I force it to skip that it gets stuck starting
> > the cups daemon.
>
> > What can I do? How can I boot my machine to command line at least? Any
> > help will be greatly appreciated.
>
> You're seeing bug #215833.
>
> The best workaround is to boot to a previous kernel (or boot with rescue
> mode from an install CD if necessary), then install the updated version of
> the linux-ubuntu-modules package.
>
>
>
> --
> mac80211 "master" interface matches existant persistent network rules
> https://bugs.launchpad.net/bugs/183968
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
_____________________________________
Akshay Dua
Student, Department of Computer Science
Portland State University

  • unnamed Edit (189 bytes, application/pgp-signature; name=signature.asc)

On Fri, 2008-04-11 at 17:31 +0000, Gregory Oschwald wrote:

> Did you follow the workaround in the bug description? The bug fix does
> not help people who upgraded to Hardy before the bug was fixed. Please
> try the following:
>
> 1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
> 2. Reboot
> /etc/udev/rules.d/70-persistent-net.rules should have been regenerated correctly.
>
Please do not give this advice.

The new udev package _WILL_ help people who upgraded to Hardy before the
upload, it corrects any existing rules file.

The above advice is wrong, and can cause people more problems that in
solves; the 70-persistent-net.rules file should never be deleted out of
hand.

Scott
--
Scott James Remnant
<email address hidden>

hirak99 (hirak99) wrote :

Scott,
I've already followed that advice and deleted the 70-persistent-net.rules file by hand. Could you please tell us a little more about what effect deleting it might have, and how one can solve that problem for those who already have done it.

Arnab.

If you deleted it, there's no way to get it back.

Deleting it will cause your interface names to change on the next reboot; thus any manual configuration for your network will be lost or (worse) confused between the different cards.

On a desktop machine with Network Manager, this tends not to matter, but on servers it can be very bad.

offby1 (offby1) wrote :

For what it's worth, I upgraded last night and things seem better now.
--
The old graybeards in the Smalltalk world may not seem
relevant, but if you ask them a question about ORM, they have been
thinking about it for 20 years.
        -- Avi Bryant

Liken Otsoa (liken) wrote :

This is not fixed for me. When I resume from suspend to ram, my network is a chaos, iwconfig shows eth0_rename as wifi, eth1 is not wifi anymore, ifdown and ifups, /etc/init.d/network restart, nothing. I need to reboot.

ipw2200 and hardy uptodate (except kernel, version 14, could it be the problem?)

------------------
IBM Thinkpad X41

Liken: if you still have problems, then you have obviously experienced a different bug. Please file a new bug and be sure to attach output of "ifconfig -a" and the contents of /etc/udev/rules.d/70-persistent-net.rules

Liken Otsoa (liken) wrote :

Scott: I did it. Bug #213158
But Greg Michalec says it may be a duplicate of this. I attach in later bug the files you indicate.

To post a comment you must log in.