The rfkill device provided by the dell_laptop module incorrectly reports state '2' on a Dell Vostro 1320. This breaks NetworkManager which uses this information to disable parts of its UI that allow the user to scan for and connect to networks.
An update of the BIOS to A03 solves the issue.
Is it possible to upgrade the BIOS without Windows? I had a go with the libsmbios tools but couldn't get them to recognise the new firmware image.
I spent (too) much time trying to update it without installing Windows. Afaik the Vostro series doesn't support updating the BIOS though libsmbios. However they provide a DOS executable, which I tried to run on freedos but didn't work because it hung while analyzing the system. So in the end I backed up my Linux partition, installed Windows to update the BIOS and restored the Linux partition.
Ugh. Unfortunately I don't want to spend £70 for a Windows license just to update the BIOs... :(
Initally I thought the bios update fixed the issue for me, but whenever I boot my laptop while the hardware killswitch (phy0) is set to blocked, wireless lan is disabled. The only way to fix this is to un-block the hardware killswitch and reload the kernel module. After that everything works fine. So if the killswitch phy0 is set to hard blocked while the kernel module dell_laptop is loaded, the killswitch dell-wifi is permanently set to hard and soft blocked and thus disabling wireless network in NetworkManager.
This bug occurs with a dell XPS M1530 too. Is there a workaround to fix it?
Add "blacklist dell_laptop" to your modprobe config (e.g. on Ubuntu /etc/modprobe.d/blacklist.conf).
I confirm that either blacklisting dell_laptop (what brings this module anyway ?) or updating the BIOS (got it without Windows) to the last version (and enabling back dell_laptop) made network-manager work again.
Just ran into this with an update to Ubuntu Karmic. Also a Dell XPS m1530. I am already running BIOS A12 which according to Dell is the highest available for the m1530. Felix's instructions (comment #7) to blacklist dell_laptop worked for me.
Had the same problem with my Dell XPS M1330. Blacklisting dell_laptop also worked.
I am getting this on my M1530 also, but I wonder if it isn't a slightly different issue. It seems to detect the switch reliably, it's just that the values are reversed. When I switch it off, rfkill list shows it as unblocked, and when I switch it back on, it shows it as blocked. So I wonder if this isn't actually a simple problem with this particular model in the dell_laptop driver?
Same problem with dell latitude X300 with "PRO/Wireless LAN 2100 3B Mini PCI Adapter" running 2.6.34 (openSUSE-11.3, module drivers/platform/x86/dell-laptop.ko not loaded (don't know why). After boot rfkill (from package 'rfkill') command reports 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes and after activating the adapter with FN F2 it reverses: 0: phy0: Wireless LAN Soft blocked: yes Hard blocked: no and that's wrong. After doing rfkill 0 unblock radio state confusion is fixed and interface is able to associate and connect. rfkill (and connection) state also persist on suspend/resume (to RAM) cycles. It looks like rfkill gets its information from /dev/rfkill and /sys/class/rfkill/rfkill0/name In contrast states in /sys/bus/pci/drivers/ipw2100/0000\:02\:04.0/rf_kill seem always be ok.