Description of problem: Hal doesn't correctly read the state of the killswitch. NetworkManager logs the error: NetworkManager: <WARN> killswitch_getpower_reply(): Error getting killswitch power: hal-ipw-killswitch-linux returned 255. Version-Release number of selected component (if applicable): kernel-2.6.25.4-39.fc9.x86_64 hal-0.5.11-1.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Start NM with wireless enabled Actual results: NetworkManager: <WARN> killswitch_getpower_reply(): Error getting killswitch power: hal-ipw-killswitch-linux returned 255. NM doesn't respond when the switch changes state Expected results: No error message, and NM automatically responds to rfkill state changes Additional info: Looks like hal-ipw-killswitch-linux is looking for /sys/class/net/<dev>/device/rf_kill but I have /sys/class/net/wlan0/device/rfkill/rfkill0/state with 0 being off and 1 being on.
Ping? I'm seeing the same with F8 on Fujitsu Lifebook S6510. Running with verbose, I see: 16:18:29.966 [I] hald_dbus.c:5037: OK for method 'GetPower' with signature '' on interface 'org.freedesktop.Hal.Device.KillSwitch' for UDI '/org/freedesktop/Hal/devices/ipw_wlan_switch' and execpath 'hal-system-killswitch-get-power' 16:18:29.966 [I] hald_dbus.c:3938: no need to enqueue 16:18:30.158 [I] device.c:1845: Removing locks from ':1.430' 16:18:30.160 [I] hald_dbus.c:3962: No more methods in queue 16:18:30.160 [I] hald_dbus.c:4025: failed with 'org.freedesktop.Hal.Device.KillSwitch.NotSupported' 'hal-ipw-killswitch-linux returned 255' Looks like it runs: 7749 execve("/usr/libexec/hal-ipw-killswitch-linux", ["hal-ipw-killswitch-linux"..., "getrfkill"...], [/* 36 vars */] <unfinished ...> But looking source it looks like it should run: /usr/libexec/hal-ipw-killswitch-linux getrfkill But even then it looks like it wants to open /sys/class/net/wmaster0/device/rf_kill which doesn't exist. Closest I can see is /sys/class/net/wmaster0/device/rfkill:rfkill1 which links to /sys/class/rfkill/rfkill1. Hope that helps.
*** This bug has been marked as a duplicate of bug 471435 ***