When trying to connect to a wireless network, I get the message "wireless is
disabled". But if I run 'iwlist scan', I can see several wireless networks.

This is a Dell Vostro 1320.

# lspci -s 0e:00 -vnn
0e:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
	Subsystem: Intel Corporation Wireless WiFi Link 5100 [8086:1321]
	Flags: bus master, fast devsel, latency 0, IRQ 32
	Memory at fa000000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [e0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number 00-22-fb-ff-ff-ab-b8-54
	Kernel driver in use: iwlagn
	Kernel modules: iwlagn

Toggling the hardware wlan enable switch makes an LED turn on and off, but
does not change NetworkManager's opinion on whether the hardware is disabled.

$ ls -l /sys/class/rfkill/
total 0
lrwxrwxrwx 1 root root 0 2009-08-29 18:03 rfkill0 -> ../../devices/virtual/rfkill/rfkill0
lrwxrwxrwx 1 root root 0 2009-08-29 18:03 rfkill1 -> ../../devices/pci0000:00/0000:00:1c.2/0000:0e:00.0/rfkill/rfkill1

$ cat /sys/class/rfkill/rfkill*/type
wlan
wlan

$ cat /sys/class/rfkill/rfkill*/state
2
1

$ nm-tool
NetworkManager Tool

State: connected

- Device: eth0  [Ifupdown (eth0)] ----------------------------------------------
  Type:              Wired
  Driver:            r8169
  State:             connected
  Default:           yes
  HW Address:        00:24:E8:C2:9E:5B

  Capabilities:
    Carrier Detect:  yes
    Speed:           1000 Mb/s

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Address:         192.168.0.231
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.0.1

    DNS:             192.168.0.1


- Device: wlan0 ----------------------------------------------------------------
  Type:              802.11 WiFi
  Driver:            iwlagn
  State:             unavailable
  Default:           no
  HW Address:        00:22:FB:AB:B8:54

  Capabilities:

  Wireless Properties
    WEP Encryption:  yes
    WPA Encryption:  yes
    WPA2 Encryption: yes

  Wireless Access Points

N.B., I changed the version number in the bug report to the version in
stable because I tried that, and only upgraded to the version in backports
to see if that would fix this bug.

severity 544217 normal
thanks

Sam Morris wrote:

Is this a regression or has NM worked before? Problem might be, that you are
mixing bpo and stable, like kernel etc.
The bpo version of NM is not officially supported.

Could you try to reproduce the problem with an up-to-date sid system please.

Michael

Not on this hardware. I just installed it today. Like I said, I only
installed the version from backports.org to see if it would fix the bug.
I've now purged and downgraded the networkmanager packages to versions
from lenny.

As for the kernel; there's no point downgrading to the kernel in stable,
since it lacks drivers for the wireless interface, and even the driver
for the ethernet interface doesn't work in 2.6.26. :(

Unfortunately I can't do this as I need to run stable on this system.
I'm just setting it up for my Dad to use.
-- 
Sam Morris
https://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

Sam Morris wrote:

If the rfkill state is not correctly detected, it's more likely a problem of
hal, so you might start checking there first.

Michael

affects 544319 network-manager
affects 544321 network-manager
block 544217 by 544319
block 544217 by 544321
thanks

The applet makes the following dbus call to find out if the wireless
hardware is disabled:

        $ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.getWirelessEnabled
        method return sender=:1.98 -> dest=:1.237 reply_serial=2
          boolean false
          boolean false

These two values correspond to the wireless_enabled and hw_rf_enabled
values from NetworkManager. These values are populated based on stuff
from HAL.

        $ hal-find-by-capability --capability killswitch | while read line; do echo $line; dbus-send --system --print-reply --dest=org.freedesktop.Hal $line org.freedesktop.Hal.Device.KillSwitch.GetPower; done
        /org/freedesktop/Hal/devices/computer_rfkill_dell_wifi_wlan
        method return sender=:1.103 -> dest=:1.285 reply_serial=2
           int32 0
        /org/freedesktop/Hal/devices/pci_8086_4232_rfkill_5100AGN_wlan
        method return sender=:1.103 -> dest=:1.287 reply_serial=2
           int32 1
        /org/freedesktop/Hal/devices/dell_wlan_switch
           int32 0

According to the HAL spec, GetPower returns 1 iff the power to the radio
is on.

At this point I took a closer look at these three killswitch devices.
The full output of 'lshal' is attached to the original bug report.

The first device is an rfkill device. If I read
/sys/devices/virtual/rfkill/rfkill0/state then I get back '2', meaning
that the radio has been disabled in hardware--incorrect! If I remove the
dell_wireless kernel module then this device disappears. Bug #544319
filed.

The second device is another rfkill device, and it seems to work
fine--its state is '1' which means the radio is on.

The third device has its 'killswitch.access_method' set to 'dell', which
causes HAL to run the dellWirelessCtl program:

        $ dellWirelessCtl --st_wlan; echo $?
        Radio Status for WLAN:
        WLAN supported
        WLAN installed
        WLAN disabled
        Status Code: 1
        1

Bug #544321 filed.

There are a few options for working around these bugs. I list them ehre
for the benefit of other users with the same problem:

     1. Tell HAL to ignore all rfkill devices. I tried to do this by
        setting the 'info.ignore' property on each of the killswitch
        devices. Unfortunately, this didn't stop NetworkManager from
        seeing them. I guess info.ignore isn't supposed to be used for
        this purpose. Is there another way to deal with this at the HAL
        level?
     2. Patch NetworkManager to override the information coming from
        HAL. The 'nm-ignore-killswitches.patch' is attached, and it does
        work. Of course, it's not suitable as anything other than a
        crude hack to workaround the issue.
     3. Fix the broken killswitch devices. The first broken device comes
        from the kernel's dell_laptop module, so that's one bug. The
        second comes from HAL's device database, but is actually queried
        with the dellWirelessCtl utility, which returns the wrong
        result. I have filed separate bugs for these issues.
     4. Work around the broken killswitch devices. The dell_laptop
        kernel module can simply be blacklisted, and removing the
        libsmbios-bin package that contains dellWirelessCtl causes
        querying HAL for its status to return an error; which in turn
        causes NetworkManager to assume that the radio is enabled.
     5. Fix the hardware. Dell have posted a BIOS update for my laptop,
        version A03, the release notes of which include "Fix kill switch
        sttatus report fail". Unfortunately, it is impossible to
        actually install this update without installing Windows, so I
        can't test that out. :(

BTW, I booted the Ubuntu 9.04 LiveCD and wireless worked fine. I ran
lshal (output attached) and noticed that they don't have the broken
computer_rfkill_dell_wifi_wlan device. Maybe this is because they have
some super secret fixes in their packages, or maybe it's because this is
a bug in a later kernel than their 2.6.28 kernel (or they don't build
the dell_laptop kernel module).

I have this same exact problem on sid, after my notebook "woke up"
from suspend state, my network manager says "Networking disabled"
and no wireless connections are being displayed.

I suggest you change the bug status back to grave, since it's incredibly
serious bug, and I see they have same problem on ubuntu as well.

This is happening on just updated Sid, hardware Lenovo X300

absinthe@havoc:~$ lspci | grep -i "wireless"
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)

absinthe@havoc:~$ ls -l /sys/class/rfkill/
total 0
lrwxrwxrwx 1 root root 0 Dec 13 19:40 rfkill0 -> ../../devices/platform/thinkpad_acpi/rfkill/rfkill0
lrwxrwxrwx 1 root root 0 Dec 13 19:40 rfkill1 -> ../../devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0/bluetooth/hci0/rfkill1
lrwxrwxrwx 1 root root 0 Dec 13 19:40 rfkill2 -> ../../devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill2

absinthe@havoc:~$ cat /sys/class/rfkill/rfkill*/type
bluetooth
bluetooth
wlan

absinthe@havoc:~$ cat /sys/class/rfkill/rfkill*/state
1
1
1

absinthe@havoc:~$ nm-tool

NetworkManager Tool

State: asleep



Adnan

I got the same problem after updating my sid (I didn't update it for
ages). I have a Dell Latitude E6400.

There are basically two ways to make it work again :
- the simplest : blacklist dell_laptop
echo "blacklist dell_laptop" > /etc/modprobe.d/blacklist_dell_laptop.conf

inconvenient : dell_laptop isn't loaded. I don't know what it does.

- somewhat more difficult : update your bios
Since I had some problems to be able to update my bios on Debian, I
wrote some detailed walkthrough on my blog :
http://www.everlong.org/blog/index.php/post/2009/12/How-to-update-the-BIOS-firmware-on-a-Dell-Laptop-using-only-Debian-Linux

I guess this resolves also the problems in bug #544319 and bug #544321.

What should we do in Debian ? Should we try to workaround this broken
bios ? The problem is that... it used to work before, even if it
wasn't perfect (I had to restart network-manager each time I used the
rfkill switch, now it works perfectly).

I can confirm this bug on a Dell E6410. What fixed the issue for me was
to downgrade network-manager and network-manager-gnome to the version
from stable (I'm running testing). I'm just posting this since other
people might want to resort to a simpler solution to have this work for
them :-).

Salaam,



Almana Financial Broker, is the home of discerning investors. We offer
independent financial advice and assist our clients to make sound investment
decisions from the array of investment opportunities available. We are
structured to render personalized services to our clients thereby ensuring
safety of capital, adequate returns on investments.



Our investors are ready to provide funding for your business expansion as
Debt/Equity finance. If you require funding, we would be able to partner
with you.



We look forward to your response, thanks and stay safe,



Abdulkader Abdi, CFA

Almana Financial Broker

Dubai, United Arab Emirates