/etc/udev/rules.d/70-persistent-net.rules file needed to be regenerated to be able to use wireless after suspend (iwl3945)

Bug #208103 reported by Mary Gardiner on 2008-03-28
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Scott James Remnant (Canonical)

Bug Description

The logic in udev according to /etc/udev/rules.d/70-persistent-net.rules seems to have changed:
Old lines look like:
 # PCI device 0x10de:0x0057 (forcedeth)
 SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0f:ea:8c:2d:36", NAME="eth0"
which causes udev to add new lines like the following after suspend/resume (module unload/reload):
 # PCI device 0x10de:0x0057 (forcedeth)
 SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth2"

After removing 70-persistent-net.rules and rebooting, the following line gets created:
 # PCI device 0x10de:0x0057 (forcedeth)
 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0f:ea:8c:2d:36", ATTR{type}=="1", NAME="eth0"

The old entries are missing an ACTION and ATTR{type} attribute, which seems to cause udev to add the extra line and therefore renaming the interface somehow.

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

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.

After upgrading pm-utils from 0.99.2-3ubuntu5 to 0.99.2-3ubuntu6 my iwl3945 wireless driver no longer worked after suspend-and-resume. A full reboot was required to make it work again. https://bugs.launchpad.net/ubuntu/+source/udev/+bug/208103/comments/5 suggested a solution that seems to work: removing /etc/udev/rules.d/70-persistent-net.rules and rebooting so that it was regenerated. I am leaving this bug open so that it can be evaluated by udev (duplicate, invalid, or a genuine problem with some earlier versions of this file).

System info was attached to bug 204040 (all with the failing pm-utils 0.99.2-3ubuntu6 and /etc/udev/rules.d/70-persistent-net.rules file installed):

$ uname -a
Linux gertrude 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux

Output of "lspci -vvnn":

Output of dmesg immediately after boot (no attempt at suspend at this point)

Output of dmesg after resuming from suspend:

Output of dmesg after resume and after running "modprobe -r iwl3945 && modprobe iwl3945" as root:

Other possibly relevant info: I am using Network Manager to manage the wireless connection, version 0.6.6-0ubuntu3.

Chris Jones (cmsj) wrote :

One of the changes in 0.99.2-3ubuntu6 is to unload network driver modules before suspending, as some of them can prevent suspends from working correctly.
For what it's worth, this behaviour of removing network drivers is how gutsy worked. Oddly, your dmesg looks like the driver gets reloaded and initialised fine on resume.

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

It does seem odd all round. My network driver worked fine in Gutsy, but that was ipw3945, not iwl3945. I will try suspending and resuming with ubuntu5 and ubuntu6 and see if there are differences in the logs. I see the evidence of the driver resuming, but "iwlist scan" never returns any results after a resume with ubuntu6.

Mary Gardiner (puzzlement) wrote :

wlan0_rename coming back up happens at 8.897105, a short time after resuming.

With 0.99.2-3ubuntu6, I have waited for ten minutes (I checked with sleep 600, this is not an estimate) with no sign of "iwlist scan" returning any APs (there are three visible usually) and network manager not budging.

Martin Nowack (martin-nowack) wrote :

I had somehow the same problem. But I don't think it is a pm-utils problem it is just triggered through suspend/resume.

You have a udev problem, because following in your dmesg output:


and after resume:


Remove the following file it gets regenerated after the next reboot:

rm /etc/udev/rules.d/70-persistent-net.rules

Maybe you've got a long bootup delay too, this will be gone too ;)

Mary Gardiner (puzzlement) wrote :

Removing /etc/udev/rules.d/70-persistent-net.rules and rebooting does mean that I can now successfully suspend and resume and my wireless still works. You don't say how you found out about this, or whether it is a known bug or not (I can't find duplicates on a search for 70-persistent-net.rules), so I am changing the Package to udev.

description: updated
Daniel Hahler (blueyed) wrote :

Confirming. Somehow it seems to be related to ATTR{type}=="1".

My broken 70-persistent-net.rules looked like this:
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0f:ea:8c:2d:36", NAME="eth0"

# PCI device 0x11ab:0x4362 (sky2)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0f:ea:8c:2d:37", NAME="eth1"

# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth2"

I've not yet rebooted, but removing the file and restarting udev (with a working connection), resulted in:
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"

Changed in udev:
importance: Undecided → High
milestone: none → ubuntu-8.04
status: New → Triaged
Daniel Hahler (blueyed) on 2008-03-30
description: updated
Alex Fraser (alex-phatcore) wrote :

The first time I tried suspending under Hardy, my wireless interface didn't come back at all. The WiFi LED on my laptop didn't turn back on.

Removing /etc/udev/rules.d/70-persistent-net.rules allows the wireless interface to be restored after suspension. And it seems to have solved a delay during bootup. Thanks!

My WiFi LED is still off despite the interface being up. This condition has persisted over several cold boots since my original failed resume from suspension.

My laptop is a Dell Inspiron 6400 with an Intel 3945ABG wireless card. Versions:
udev 117-4ubuntu1
network-manager 0.6.6-0ubuntu4

Chris Cheney (ccheney) wrote :

I experienced this problem as well, here is the udiff of what my file looked like before and after:

diff -Nrua 70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules
--- 70-persistent-net.rules 2008-01-16 15:14:32.000000000 -0600
+++ /etc/udev/rules.d/70-persistent-net.rules 2008-03-31 14:28:58.000000000 -0500
@@ -1,11 +1,10 @@
-# This file maintains persistent names for network interfaces.
-# See udev(7) for syntax.
+# This file was automatically generated by the /lib/udev/write_net_rules
+# program run by the persistent-net-generator.rules rules file.
-# Entries are automatically added by the 75-persistent-net-generator.rules
-# file; however you are also free to add your own entries.
+# You can modify it, as long as you keep each rule on a single line.

 # PCI device 0x11ab:0x4353 (sky2)
-SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:a0:d1:72:01:cf", NAME="eth0"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:d1:72:01:cf", ATTR{type}=="1", NAME="eth0"

-# PCI device 0x8086:0x4222 (ipw3945)
-SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:19:d2:8a:0c:19", NAME="eth1"
+# PCI device 0x8086:0x4222 (iwl3945)
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:d2:8a:0c:19", ATTR{type}=="1", NAME="wlan0"

Steve Langasek (vorlon) wrote :

It seems to me that the obvious fix here would be for udev on upgrade to sed in the additional fields if they're missing, but I'm not sure if that's always The Right Thing -- Scott?

It isn't always the right thing, sadly

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

The wifi LED not working when using the iwl3945 driver is a separate bug: bug 176090.

Mary Gardiner (puzzlement) wrote :

Bug 204709 (which has been triaged against the kernel) might be the same bug.

description: updated
Daniel Hahler (blueyed) wrote :

What about removing the old file in udev's postinst and let it being generated, or trigger a regeneration? (rm_conffile, http://wiki.debian.org/DpkgConffileHandling)

Steve Langasek (vorlon) wrote :

On Tue, Apr 01, 2008 at 10:21:45PM -0000, Daniel Hahler wrote:
> What about removing the old file in udev's postinst and let it being
> generated

This defeats the purpose of having that file, which is to ensure that
network device names are persistent across reboots.

description: updated
Colin Watson (cjwatson) on 2008-04-02
Changed in udev:
assignee: nobody → keybuk
To post a comment you must log in.