Hide Forgot
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).
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!
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
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.
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
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
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?] ).
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.
correction card is atheros ar5001 which seems to use the ath5k driver package
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).
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).
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?
'rfkill list' output manually transcribed: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no
(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
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
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.