Description of problem: A fresh boot of the computer shows my AP, but after restarting NM it doesn't show up again. Trying to connect to another network (with a wrong password) will generally show my AP again after the connection attempt fails. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.9.1.svn3476.fc9.i386 Not sure which version this worked in last. Haven't been using the latest for a few weeks since the usb-modem caused it to crash. (And I didn't file a bug for that, sorry) I'll try a few older version a see when I've submitted this. How reproducible: Every time. Results very though. Sometimes it shows many APs (18) but usually it shows 0 to 6 APs. Sometimes starting with 0 and slowly adding more until it stops adding around 5 or 6. Steps to Reproduce: 1. Reboot 2. Restart service NetworkManager Actual results: Few or no APs in the list Expected results: My AP and many others should show up. Additional info: using "modprobe iwl4965 disable_hw_scan=1" seems to give better result with find the AP by using "iwlist scan" but it doesn't show up in the applet list. iwevent shows "Scan request completed" but it still doesn't show up in the applet. Flipping the "Enabled wireless" switch twice in the applet can also trigger the APs show up in the interface.
I saw a similar problem, also with an iwl4965. I logged in, connected to my AP, then logged out (for non-NM-related reasons). When I logged back in, NM could see all of the wireless networks in the area *except* the one I'd been connected to before. Logging out and back in again brought it back.
When this happens, can you: [dcbw@localhost ~]$ sudo dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.getInterface string:wlan0 method return sender=:1.7 -> dest=:1.716 reply_serial=2 object path "/fi/epitest/hostap/WPASupplicant/Interfaces/27" then take the returned object path and feed it back into the supplicant like so: [dcbw@localhost ~]$ sudo dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant/Interfaces/27 fi.epitest.hostap.WPASupplicant.Interface.scanResults Is your desired AP in the scan results reported by the supplicant? (look for your AP's MAC address in the list) Then, can you do at least two consecutive 'iwlist wlan0 scan' commands and see if the AP you care about shows up in the output of at least one of them? I've seen problems like this too with iwl4965, but doing the iwlist does _not_ show the desired AP after repeated scans. After doing the iwlist scans, if you find your AP in the output of iwlist, run the supplicant commands again and see if your AP shows up in the output from the supplicant. Let me know, thanks.
No go. Still doesn't work. [root@rr-laptop ~]# dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.getInterface string:wlan0 method return sender=:1.0 -> dest=:1.645 reply_serial=2 object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0" [root@rr-laptop ~]# dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant/Interfaces/0 fi.epitest.hostap.WPASupplicant.Interface.scanResults method return sender=:1.0 -> dest=:1.650 reply_serial=2 array [ object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0019e332da87" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00a0c5805fdf" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00195bd9eb02" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0013461d18fd" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001b2f579da0" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0011500da7e0" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00146c4c03c8" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0014bf261abc" ] [root@rr-laptop ~]# iwlist wlan0 scan didn't show my AP [root@rr-laptop ~]# iwlist wlan0 scan didn't show my AP either. -- doing "create new network" and let it fail so it will find my AP again --- My AP shows up as the second on the list. [root@rr-laptop ~]# dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.getInterface string:wlan0 method return sender=:1.0 -> dest=:1.698 reply_serial=2 object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0" [root@rr-laptop ~]# dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply /fi/epitest/hostap/WPASupplicant/Interfaces/0 fi.epitest.hostap.WPASupplicant.Interface.scanResults method return sender=:1.0 -> dest=:1.701 reply_serial=2 array [ object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00173fe24bd5" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00173f073528" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001b2f579da0" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0011500da7e0" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001b1192a254" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0011500da7d7" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0014bf261abc" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/00904c7e0064" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/0013f776514e" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001d4fa8b21f" object path "/fi/epitest/hostap/WPASupplicant/Interfaces/0/BSSIDs/001cdf029610" ]
John; seen this on jrb's 4965 as well with rawhide; sometimes no matter how many iwlist scans you do, it won't show rh-wireless. Have to rmmod/modprobe the module to find it again. Not sure what debug output you'd like; are current rawhide kernels built with debugging which we could enable next time he sees, so we could dump out exactly what mac80211 thinks it's getting for scan results?
I posted this to the NM list but it makes sense to have this here as well. I tested older kernels to figure out if it was a kernel bug and it turns out that it breaks between these two releases. 2.6.25-0.121.rc5.git4.fc9 doesn't work 2.6.25-0.120.rc5.git3.fc9 works Comment #4. Connecting to a wireless network with a wrong password will also make all APs visisble again.
Well, comparing the above kernels for changes to wireless was fruitless, so I retested older kernels and came out with a different result. I'm pretty sure that rc5.git3 worked, but it seems it doesn't work now. Really strange. Anyway. I tested these kernels by booting by doing "service NetworkManager restart" and waiting for the applet to reconnect. I restarted NM twice with each kernel. And waited a minute or two between the restarts of NM to make sure it had time to locate the AP. 2.6.25-0.95.rc4.fc9 works 2.6.25-0.107.rc5.fc9 works 2.6.25-0.111.rc5.git1.fc9 works 2.6.25-0.113.rc5.git2.fc9 doesn't work 2.6.25-0.120.rc5.git3.fc9 doesn't work 2.6.25-0.121.rc5.git4.fc9 doesn't work I'll download the source for rc5.git1 and rc5.git2 and start comparing changes.
All of the kernels you have mentioned are a couple of weeks old. What is the latest kernel you have tried?
I run the latest kernels from rawhide and keep my system up to date. Currently running: 2.6.25-0.182.rc7.git6.fc9.i686 This problem has persisted since 2.6.25-0.113.rc5.git2.fc9. Not that I was aware of where the problems was a the time. That took a while to figure out. The kernels listed above where just used to pinpoint the release which introduced the bug. I also have a laptop running the same rawhide updates but using a iwl3945 card. That machine isn't affected by the bug.
Ugh, so you are saying that iwl3945 is ok but iwl4965 is broken? I'll never grok the mysteries of the Intel wireless hardware...
I am seeing it both with the 3945 and 4965, but more reliably with the 3945 -- especially after a suspend.
(In reply to comment #9) > Ugh, so you are saying that iwl3945 is ok but iwl4965 is broken? I'll never > grok the mysteries of the Intel wireless hardware... I have a wireless card using iwl3945, and it doesn't work with kernel-2.6.25-0.204.rc8.git4.fc9.i686
Same results as comment #10, comment #11 here, with iwl3945 and kernel-2.6.25-0.204.rc8.git4.fc9.x86_64.
FWIW, I see this with iwl4965 as well. 'modprobe -r iwl4965 ; modprobe iwl4965' seems to restore normal operation (not that this is an acceptable solution). Hopefully we can get some input from Intel as to why the driver seems to quit scanning?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This seems to be working again. APs show up after restarting NM and even after suspend. Thanks and feel free to close this bug.
(In reply to comment #15) > This seems to be working again. APs show up after restarting NM and even after > suspend. > Thanks and feel free to close this bug. Which version of the kernel is that with? I'm still seeing this with a pretty up-to-date laptop using updates-testing.
I'm currently using kernel 2.6.25.6-55.fc9.i686 NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386 on two laptops with iwl3945. I might have changed the password on the missing AP from WEP ASCII to WEP passphrase in the time that has passed since reporting this bug. I didn't notice when it started working. I just realized that my AP was suddenly present after a suspend-to-ram so I started testing if the bug was gone. I just tried changing it back to WEP ASCII but it still finds the AP. Both laptops had 4 APs in the list (nm-applet) after working all night. Suspending one of them to test the new WEP key brought up 10 APs after suspend. Including my own.