NM doesnt forget currently cached APs when there are zero APs in proximity

[Jamie Lokier]

Binary package hint: network-manager

This was originally a comment in bug #289796, but it is a different bug.

The following issue did not occur on Hardy. My system is now upgraded to Intrepid.

After resuming from suspend, the list of APs was not cleared for a long time (at least 50 minutes), when the laptop had no APs in range. Explicit scans from the command line did not result in NM's list refreshing. Details:

I have just suspended the laptop at home, where there's an AP called "christopher" which I use, and another one in range.

I resumed about 50 minutes ago, in another place with no APs in range. nm-applet is still showing the two APs which were in range when I suspended - after 50 minutes! It should have had plenty of time to do another scan.

I've just forced a scan using "sudo iwlist wlan0 scanning", and it says "wlan0 No scan results".
5 minutes after doing that (then doing it again), nm-applet is _still_ showing those 2 APs from before the laptop was suspended.

I can even select "christopher", the AP I used when suspended, and it will try to connect to it. After the attempt fails, it pops up the dialog asking for the AP key.

It appears NetworkManager is simply not refreshing its list, even though the Wi-Fi driver has done multiple scans itself in this time. I did see this behaviour in Hardy occasionally, where nm-applet took annoyingly long to notice changes despite explicit manual scans with iwlist, but nm-applet would always catch up after a couple of minutes.

Arguably, a second bug is: Popping up a dialog asking for the AP key for an AP which is not in range (does not show up in a scan) _and_ is not / has never been in the list managed by "Connect to Hidden Wireless Network". If an AP was in range when it was selected in the UI, but is no longer showing in scans by the time NM tries to connect, and the AP is not believed to be hidden, then asking for the AP key seems like the wrong thing to do, and instead it could alert that it has gone out of range (if requested explicitly from the UI) or simply try another AP (if the one out of range was chosen automatically).

[Romano Giannetti (romano-giannetti)]

It happens to me, too. Frequent requests for keys for known network not in range or simply dropped. If added to the fact that even if I connect a wired network NM continues to scan and try to connect to the wireless ones, it results in a quite annoying thing.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release the Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

[Romano Giannetti (romano-giannetti)]

I think this has been really fixed in the kernel drivers. In Karmic the problem is gone. Have a look
at http://blogs.gnome.org/dcbw/2009/02/26/suspendresume-vs-networkmanager/