Description of problem: I have recently noticed that while RF kill switch works correctly when it comes to disabling the network, it does not work that well with respect to bringing it back. This is on a Toshiba Satellite A100-847 laptop (iwl3945, hardware kill switch). Version-Release number of selected component (if applicable): 0.7.0-0.6.7.svn3370.fc8 How reproducible: always Steps to Reproduce: 1. get an affected laptop 2. connect to a wireless network 3. flip RF kill switch on 4. flip RF kill switch off Actual results: PC stays disconnected Expected results: PC reconnects to a wireless network Additional info: Restarting NetworkManager service helps in this case.
Created attachment 300396 [details] log of flipping the kill switch to 'on'
When you bring the device back, what does: /sbin/iwlist wlan0 scan report?
wlan0 Interface doesn't support scanning : Network is down
Ok, can you bring the device up with 'ifconfig wlan0 up' and then try the '/sbin/iwlist wlan0 scan'? Lets see what that says. Thanks!
[root@snowball ~]# ifconfig wlan0 up [root@snowball ~]# iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:18:F8:EC:03:D9 ESSID:"sikorski_czahary" Mode:Master Frequency:2.437 GHz (Channel 6) Channel:6 Quality=59/100 Signal level=-72 dBm Noise level=-67 dBm Encryption key:on IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s 12 Mb/s; 48 Mb/s Extra:tsf=0000011bfbe92c9a Cell 02 - Address: 00:1B:11:FA:F7:C2 ESSID:"orange" Mode:Master Frequency:2.462 GHz (Channel 11) Channel:11 Quality=43/100 Signal level=-83 dBm Noise level=-67 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : TKIP CCMP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : TKIP CCMP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=0000004161b52183 Cell 03 - Address: 00:02:6F:45:85:D9 ESSID:"gwarant_5" Mode:Master Frequency:2.412 GHz (Channel 1) Channel:1 Quality=38/100 Signal level=-86 dBm Noise level=-67 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=00000039e02ca184 ifconfig wlan0 up makes NM aware of the wireless - here is the /var/log/messages output: Apr 11 16:46:13 localhost kernel: ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 Apr 11 16:46:13 localhost kernel: Registered led device: iwl-phy0:radio Apr 11 16:46:13 localhost kernel: Registered led device: iwl-phy0:assoc Apr 11 16:46:13 localhost kernel: Registered led device: iwl-phy0:RX Apr 11 16:46:13 localhost kernel: Registered led device: iwl-phy0:TX Apr 11 16:46:13 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready Apr 11 16:46:17 localhost NetworkManager: <info> Wireless now enabled by radio killswitch Unfortunately, I can't connect to my wlan until I restart NM: Apr 11 16:46:32 localhost NetworkManager: <info> User request for activation of wlan0. Apr 11 16:46:32 localhost NetworkManager: <info> Activating device wlan0 Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0/wireless): connection 'Auto sikorski_czahary' has security, and secrets exist. No new secrets needed. Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'ssid' value 'sikorski_czahary' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'scan_ssid' value '1' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'psk' value '<omitted>' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'proto' value 'WPA RSN' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'pairwise' value 'TKIP CCMP' Apr 11 16:46:32 localhost NetworkManager: <info> Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Apr 11 16:46:32 localhost NetworkManager: nm_supplicant_interface_set_config: assertion `NM_IS_SUPPLICANT_INTERFACE (self)' failed Apr 11 16:46:32 localhost NetworkManager: <WARN> real_act_stage2_config(): Activation (wlan0/wireless): couldn't send wireless configuration to the supplicant. Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) failed for access point (sikorski_czahary) Apr 11 16:46:32 localhost NetworkManager: <info> Marking connection 'Auto sikorski_czahary' invalid. Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) failed. Apr 11 16:46:32 localhost NetworkManager: <info> Deactivating device wlan0. Apr 11 16:46:32 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just tested it in Fedora 10. While it is possible to get the network back, while the kill switch is engaged NM still attempts to connect to wlan, eventually popping up an passphrase window. It seems it is not aware of the kill switch.
Created attachment 324726 [details] related part of /var/log messages This is from turning on the kill switch to cancelling the passphase dialog.
This is a HAL bug; if HAL knows about the killswitch states, then NetworkManager will know about them and act accordingly. Apparently HAL doesn't know that you've flipped the killswitch.
Yeah, seems you're right: lshal -m does not record anything upon flipping the killswitch.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
It works with an up-to-date Fedora 11.