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

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.

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.

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.

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:

wlan0_rename

and after resume:

wmaster0

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

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.

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"

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
linux-image-generic 2.6.24.12.13
network-manager 0.6.6-0ubuntu4

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"

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

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

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

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)

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.