wireless appears nonexistent after resume from suspend

[Tomas Cassidy]

Wireless network access seems to disappear from Network Manager after resuming from suspend on my Dell Inspiron 1520 laptop. Right-clicking on the Network Manager applet before suspend shows options for both "Enable Networking" and "Enable Wireless" while doing the same after resuming from suspend shows only the "Enable Networking" option. The wireless card is an Intel 3945 chipset and the driver used is iwl3945. lsmod shows the iwl3945 driver as loaded both before and after suspend.

[David Tomaschik (matir)]

I have a laptop with the same card and do not see that behavior as of today. Does iwconfig show the card after a resume?

[Tomas Cassidy (tomas-cassidy)]

I think I managed to solve this problem earlier today. The wireless interface had been given the name "wlan0_rename" when I switched from the ipw3945 driver to the iwl3945 driver. This caused different output from both iwconfig and ifconfig for the interface name. iwconfig gave the correct name, while it was the incorrect ifconfig output used for the suspend scripts. Removing the file /etc/udev/rules.d/70-persistent-net.rules allowed the system to recreate this file for the new driver, changing the interface name back to "wlan0". (it also introduced a new interface called "wmaster0" :-s). It all seems to be working properly now that the interface name has changed back to "wlan0".

[Matt Price (matt-price)]

Confirming this bug for my dell latitude d820, with a similar chipset (rev 2). your fix also showed the way to a fix for me; moving the old 70-persistent-net.rules resulted in a new one, which itself did not fix the problem; but experimenting with various versions did lead to success. for the record, here's my working 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:0x1600 (tg3)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:15:c5:0a:21:b5", ATTR{type}=="1", NAME="eth0"

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:02:5d:f1:a5", ATTR{type}=="1", NAME="eth1"

thanks for the help!

matt

[Tomas Cassidy (tomas-cassidy)]

After reading the previous comment, I though I should post my new autogenerated 70-persistent-net.rules file incase other people are interested in what was generated.

# 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:0x170c (b44)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1d:09:bc:e9:ea", NAME="eth0"

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1c:bf:8b:4d:01", ATTRS{type}=="1", NAME="wlan0"

[Andrew King (anders-king-00)]

I also have experienced this problem after changing from ipw3945 to iwl3945. Removing /etc/udev/rules.d/70-persistent-net.rules and rebooting fixed it.

[Thomas Novin (thomasn80)]

This is probably related to https://bugs.launchpad.net/ubuntu/+source/udev/+bug/183968

[Tomas Cassidy (tomas-cassidy)]

This is probably related to https://bugs.launchpad.net/ubuntu/+source/udev/+bug/183968

Yes. It seems like it is. That other bug report also seems to have more information on the problem than this one.