Bug 595931 - [rfkill] state not correctly detected on boot
Summary: [rfkill] state not correctly detected on boot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: John Feeney
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-25 22:57 UTC by Frederik Hertzum
Modified: 2013-01-10 07:24 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-27 16:39:55 UTC


Attachments (Terms of Use)

Description Frederik Hertzum 2010-05-25 22:57:49 UTC
Description of problem:
NetworkManager insists that all wireless connections are disabled at boot time, irregardless of what the setting is when shutting down the machine. 

Version-Release number of selected component (if applicable):
0.8.1

How reproducible:
Always

Steps to Reproduce:
1. Start up a machine with a wireless network and log in
2. Set wireless connections to be enabled
3. Reboot the machine and log in
  
Actual results:
NetworkManager has disabled all wireless connections, meaning automatic logging on to wireless network connections is not possible (you have to manually enable wireless connections)

Expected results:
Networkmanager remembers the last setting used for wireless networks. 

Additional info:
This may be a duplicate of a few of the bugs against NetworkManager already, but the descriptions provided allow me to believe it is different (but related).

I have only tested this on one machine, which has an Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection card installed (uses the iwlagn driver).

Comment 1 Dan Williams 2010-05-26 10:11:41 UTC
I think it's the same as some of the other bugs, but just to be sure... after reboot when this problem appears, can you attach:

/var/lib/NetworkManager/NetworkManager.state

and then also grab the output of:

rfkill list


thanks!

Comment 2 Frederik Hertzum 2010-05-31 03:15:19 UTC
cat /var/lib/NetworkManager/NetworkManager.state:

[main]
NetworkingEnabled=true
WirelessEnabled=false
WWANEnabled=true

rfkill list
0: acer-wireless: Wireless LAN
       Soft blocked: yes
       Hard blocked: no
0: hci0: Bluetooth
       Soft blocked: no
       Hard blocked: no
0: phy0: Wireless LAN
       Soft blocked: no
       Hard blocked: no

Comment 3 Frederik Hertzum 2010-06-04 23:25:10 UTC
I have tested with another computer which doesn't have this bug, despite everything being setup the exact same way (I even copied the $HOME of my user account on the other machine) -- there is one difference though. The machine with the bug has (most of) it's disc encrypted. Just in case it matters.

Comment 4 skippy@home 2010-06-07 13:10:18 UTC
I may be able to add a little bit of detail to Frederik's report.  I have an HP G60 notebook with whole disk encryption (/boot now on a 500MB partition on a thumb drive).  On FC 12, fully updated wireless and wired worked flawlessly - poweroff, reboots, no problems.  

A while back (after 13 released), I tried the "yum" upgrade to 13 method from documentation that warns it might not work terribly well.  This was after I realized my old 128MB /boot thumb drive was too small for the "right" upgrade.  I lost wireless on first boot after the yum upgrade.  Assuming it was a problem with the upgrade, I backed up what I cared about and installed from DVD (don't ask - the backing up part took quite a bit longer than it should have).  After installation, wireless again didn't work - the Network Manager "Enable wireless" radio button was disabled.  I pounded on the hardware button repeatedly to no avail, rebooted many times, read documentation, searched the internet, looked for anything in BIOS, and finally, in desperation, went to HP's support site. I searched HP forums and read lots of reports of Windows/HP users complaining about dead wireless cards.  Every attempt to do anything with the card resulted in an RF-Kill error message (OK, so I hadn't tried or heard of the the rfkill program at this point...).  Below is the dmesg output pertaining to the built-in card on the notebook:    

cfg80211: Calling CRDA to update world regulatory domain
ath5k 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath5k 0000:02:00.0: setting latency timer to 64
ath5k 0000:02:00.0: registered as 'phy0'
  alloc irq_desc for 22 on node -1
  alloc kstat_irqs on node -1
cfg80211: World regulatory domain updated:
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
ath: EEPROM regdomain: 0x64
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x64
phy0: Selected rate control algorithm 'minstrel'
name_count maxed, losing inode data: dev=00:07, inode=10763
name_count maxed, losing inode data: dev=00:07, inode=10831
name_count maxed, losing inode data: dev=00:07, inode=10831
name_count maxed, losing inode data: dev=00:07, inode=10831
name_count maxed, losing inode data: dev=00:07, inode=10831
name_count maxed, losing inode data: dev=00:07, inode=10831
name_count maxed, losing inode data: dev=00:07, inode=10831
Registered led device: ath5k-phy0::rx
Registered led device: ath5k-phy0::tx
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
cfg80211: Calling CRDA for country: KR
cfg80211: Regulatory domain changed to country: KR
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5250000 KHz - 5330000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5490000 KHz - 5630000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)
    (5735000 KHz - 5815000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)

So, I plugged in a bright, shiny, new, netgear USB adaptor, dmesg output below.

usb 2-5: new high speed USB device using ehci_hcd and address 3
usb 2-5: New USB device found, idVendor=0846, idProduct=9001
usb 2-5: New USB device strings: Mfr=16, Product=32, SerialNumber=48
usb 2-5: Product: USB2.0 WLAN
usb 2-5: Manufacturer: ATHER
usb 2-5: SerialNumber: 12345
usb 2-5: reset high speed USB device using ehci_hcd and address 3
usb 2-5: firmware: requesting ar9170.fw
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy1: Selected rate control algorithm 'minstrel'
cfg80211: Calling CRDA for country: US
Registered led device: ar9170-phy1::tx
Registered led device: ar9170-phy1::assoc
usb 2-5: Atheros AR9170 is registered as 'phy1'
usbcore: registered new interface driver ar9170usb
cfg80211: Current regulatory domain intersected: 
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 20000 KHz), (N/A, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 1700 mBm)
    (5250000 KHz - 5330000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5490000 KHz - 5600000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5815000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)

NetworkManager wouldn't do anyhting with it, but if I used iwconfig/ifconfig/iwlist wlan0 scanning, I could see results.  Now I must be on to something.  

If I just reboot, all will be well.  The onboard wireless must be dead...  or not.  After the reboot, both the USB and onboard wireless adaptors come up dead.  RF-Kill messages and all.  OK, research RF-Kill.  Hmmmm, kernel API, userland, blah blah blah.  yum install rfkill.  rfkill list:

0: hp-wifi: Wireless LAN
        Soft blocked: yes
        Hard blocked: yes
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
2: phy1: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Well that's interesting...  Push button on NB, rfkill list again:

0: hp-wifi: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
2: phy1: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Hmmm, progress.  rfkill unblock [0...2]:

0: hp-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: phy1: Wireless LAN
        Soft blocked: no
        Hard blocked: no

And I can start configuring stuff - still not taking configurations properly, but at least I'm part of the way there.  Reboot, nada.  rfkill list:

0: hp-wifi: Wireless LAN
        Soft blocked: yes
        Hard blocked: yes
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
2: phy1: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Ok, the notebook never turned the HW RF-Kill block on before (well not that I can recall in Vista, Gentoo, FC11, or FC12), but now I get it every boot.  And the soft block was never set before.  Checking /var/log/messages and the only indication is:

Jun  7 05:50:12 host NetworkManager[1276]: <info> found WiFi radio killswitch rfkill1 (at /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/ieee80211/phy0/rfkill1) (driver <unknown>)
Jun  7 05:50:12 host NetworkManager[1276]: <info> found WiFi radio killswitch rfkill0 (at /sys/devices/platform/hp-wmi/rfkill/rfkill0) (driver hp-wmi)

.....And later this evening.....

Jun  7 20:11:17 roamz NetworkManager[1320]: <info> found WiFi radio killswitch rfkill3 (at /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/ieee80211/phy2/rfkill3) (driver <unknown>)

Jun  7 20:21:33 roamz yum: Installed: rfkill-0.4-1.fc13.x86_64

Jun  7 20:25:42 roamz NetworkManager[1320]: <info> radio killswitch /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/ieee80211/phy2/rfkill3 disappeared
  
.....And after another reboot.....

Jun  7 21:44:59 roamz NetworkManager[1322]: <info> found WiFi radio killswitch rfkill1 (at /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/ieee80211/phy1/rfkill1) (driver <unknown>)
Jun  7 21:44:59 roamz NetworkManager[1322]: <info> found WiFi radio killswitch rfkill2 (at /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/ieee80211/phy0/rfkill2) (driver <unknown>)
Jun  7 21:44:59 roamz NetworkManager[1322]: <info> found WiFi radio killswitch rfkill0 (at /sys/devices/platform/hp-wmi/rfkill/rfkill0) (driver hp-wmi)

rfkill list:

0: hp-wifi: Wireless LAN
        Soft blocked: yes
        Hard blocked: yes
1: phy1: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

It is during boot that the wireless button turns from 'orange' to 'blue' (it seems that 'orange'=RF-Kill block no, 'blue'=no wireless for you).  After su'ing and using rfkill AND the button, I'm back to orange and can work on getting NM to actually connect to my access point, but every reboot means a su, button push, and rfkill unblock.  

Anyone have any ideas or need more information?  I'm willing to try almost anything because there's nothing on this notebook, yet.

Thanks,

Skippy@home

Comment 5 skippy@home 2010-06-07 13:22:42 UTC
Oops, the section that reads:

NetworkManager wouldn't do anyhting with it, but if I used
iwconfig/ifconfig/iwlist wlan0 scanning, I could see results.  Now I must be on
to something.

should read:

NetworkManager wouldn't do anyhting with it, but if I used
iwconfig/ifconfig/iwlist wlan1 scanning, I could see results.  Now I must be on
to something.

...Sorry

-Skippy

Comment 6 collura 2010-06-10 00:01:20 UTC
for what its worth i have a similar reconnect situation 
(no auto reconnect on boot) 

when i do clean install of f13 by install dvd (gnome window manager) 
(ran updater by hardwire) wifi works fine aside from needing manual re-connect at each reboot.  

card is atheros ar5001 which seems to use ar9170 driver package? 
(works great in fc12, but only marginally works in fc13 [as described above])



( probably unrelated but note however for an install from f13 kde window manager live cd the wifi doesnt seem to connect at all [ran updater by hardwire] but thats off topic of this 'reconnect' bug thread [and might just be me missing a driver?] ).

Comment 7 Frederik Hertzum 2010-06-10 21:59:32 UTC
Just to clarify, my wifi card works fine -- the drivers are working fine as well. The problem was present from first boot. This is a NM problem in combination with something else.

And thank you to Skippy for that very long comment. It looks to me like your problems are different from mine, however (if I read your report right).

I'm going to reinstall Fedora 13 on the laptop without encryption to see if it fixes the problem.

Comment 8 collura 2010-06-12 06:13:23 UTC
correction card is atheros ar5001 which seems to use the ath5k driver package

Comment 9 Frederik Hertzum 2010-06-12 12:44:00 UTC
The problem persists with non-encrypted installations (which what was expected).
The problem however, does not exist with a 802.11n card using the rt2800 drivers (those drivers have their own problems, but that's for another bugreport).

Comment 10 Dan Williams 2010-06-15 18:32:52 UTC
NM appears to be operating *correctly* by respecting the state of the kernels' reported RFKILL switches.  This appears to be more of an issue of the kernel drivers not correctly detecting rfkill state, or BIOS not saving the rfkill state if it has that capability (which most do).

Comment 11 Dan Williams 2010-06-15 18:40:14 UTC
Basically, if you do 'rfkill list' and you see that *any* wifi switch has either a hard or soft block on it, then your wifi is killed, and if that's not what you want, you need to either unkill it, or we need to figure out why it's killed when you don't expect it to be...

Frederik, is it the case that when this problem occurs, 'rfkill list' always shows at least one wifi killswitch as hard or soft blocked?

Comment 12 collura 2010-07-09 19:32:51 UTC
'rfkill list' output manually transcribed:

0: phy0: Wireless LAN
      Soft blocked: no
      Hard blocked: no

Comment 13 Frederik Hertzum 2010-07-11 06:41:10 UTC
(In reply to comment #11)
> Basically, if you do 'rfkill list' and you see that *any* wifi switch has
> either a hard or soft block on it, then your wifi is killed, and if that's not
> what you want, you need to either unkill it, or we need to figure out why it's
> killed when you don't expect it to be...
> 
> Frederik, is it the case that when this problem occurs, 'rfkill list' always
> shows at least one wifi killswitch as hard or soft blocked?    

after having done the latest yum upgrade cycle, rfkill still, persistantly gives the same result:

0: acer-wireless: Wireless LAN
       Soft blocked: yes
       Hard blocked: no
0: hci0: Bluetooth
       Soft blocked: no
       Hard blocked: no
0: phy0: Wireless LAN
       Soft blocked: no
       Hard blocked: no

Comment 14 Bug Zapper 2011-06-02 13:29:40 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 15 Bug Zapper 2011-06-27 16:39:55 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.


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