Bug 438613 - NM fails to display access points after restarting NM
NM fails to display access points after restarting NM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-22 17:46 EDT by Rene Rask
Modified: 2008-06-23 23:55 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-23 15:32:13 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)

  None (edit)
Description Rene Rask 2008-03-22 17:46:02 EDT
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.
Comment 1 Dan Winship 2008-03-27 13:45:48 EDT
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.
Comment 2 Dan Williams 2008-03-31 12:29:23 EDT
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.
Comment 3 Rene Rask 2008-03-31 12:59:41 EDT
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"
   ]


Comment 4 Dan Williams 2008-03-31 14:11:19 EDT
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?
Comment 5 Rene Rask 2008-04-01 01:25:17 EDT
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.

Comment 6 Rene Rask 2008-04-01 03:21:13 EDT
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.
Comment 7 John W. Linville 2008-04-01 09:24:13 EDT
All of the kernels you have mentioned are a couple of weeks old.  What is the 
latest kernel you have tried?
Comment 8 Rene Rask 2008-04-01 10:02:52 EDT
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.
Comment 9 John W. Linville 2008-04-01 10:52:01 EDT
Ugh, so you are saying that iwl3945 is ok but iwl4965 is broken?  I'll never 
grok the mysteries of the Intel wireless hardware...
Comment 10 Jonathan Blandford 2008-04-01 12:44:52 EDT
I am seeing it both with the 3945 and 4965, but more reliably with the 3945 --
especially after a suspend.
Comment 11 Bastien Nocera 2008-04-10 13:10:12 EDT
(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
Comment 12 Paul W. Frields 2008-04-10 17:25:17 EDT
Same results as comment #10, comment #11 here, with iwl3945 and
kernel-2.6.25-0.204.rc8.git4.fc9.x86_64.
Comment 13 John W. Linville 2008-04-29 16:35:54 EDT
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?
Comment 14 Bug Zapper 2008-05-14 02:48:08 EDT
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
Comment 15 Rene Rask 2008-06-22 23:59:53 EDT
This seems to be working again. APs show up after restarting NM and even after
suspend.
Thanks and feel free to close this bug.
Comment 16 Bastien Nocera 2008-06-23 15:56:39 EDT
(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.
Comment 17 Rene Rask 2008-06-23 23:55:04 EDT
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.

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