Bug 440590 - Network does not come back up after flipping RF kill switch back to off
Network does not come back up after flipping RF kill switch back to off
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-04 04:44 EDT by Julian Sikorski
Modified: 2009-07-22 05:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-22 05:33:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log of flipping the kill switch to 'on' (1.87 KB, text/plain)
2008-04-04 04:44 EDT, Julian Sikorski
no flags Details
related part of /var/log messages (4.52 KB, text/plain)
2008-11-26 09:51 EST, Julian Sikorski
no flags Details

  None (edit)
Description Julian Sikorski 2008-04-04 04:44:35 EDT
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.
Comment 1 Julian Sikorski 2008-04-04 04:44:35 EDT
Created attachment 300396 [details]
log of flipping the kill switch to 'on'
Comment 2 Dan Williams 2008-04-10 12:18:23 EDT
When you bring the device back, what does:

/sbin/iwlist wlan0 scan

report?
Comment 3 Julian Sikorski 2008-04-10 17:09:44 EDT
wlan0     Interface doesn't support scanning : Network is down
Comment 4 Dan Williams 2008-04-10 18:49:18 EDT
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!
Comment 5 Julian Sikorski 2008-04-11 10:49:59 EDT
[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.
Comment 6 Bug Zapper 2008-11-26 05:24:04 EST
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
Comment 7 Julian Sikorski 2008-11-26 09:45:31 EST
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.
Comment 8 Julian Sikorski 2008-11-26 09:51:40 EST
Created attachment 324726 [details]
related part of /var/log messages

This is from turning on the kill switch to cancelling the passphase dialog.
Comment 9 Dan Williams 2008-11-26 10:49:05 EST
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.
Comment 10 Julian Sikorski 2008-11-26 13:08:03 EST
Yeah, seems you're right: lshal -m does not record anything upon flipping the killswitch.
Comment 11 Bug Zapper 2009-01-09 01:19:46 EST
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.
Comment 12 Julian Sikorski 2009-07-22 05:33:51 EDT
It works with an up-to-date Fedora 11.

Note You need to log in before you can comment on or make changes to this bug.