NetworkManager should forget list of currently cached APs after resume (WAS: wlan roaming problems after wakeup from hibernate)

[jjwin2k]

Binary package hint: network-manager

Found: In intrepid
Apparently the network manager applet does not clear the names of found wlans after / before entering hibernation mode.
This causes a minor inconvenience, 'cause after putting your notebook into hibernation and changing your location, e.g. going to work, the network manager tries to connect to the old wlan.

Therefore one explicitly has to tell the manager to connect to another network.
It would be useful to clear the old names.

[Alexander Sack (asac)]

NM will not try to connect to a wireless network if its not visible.

If you can reproduce this, please attach a complete syslog taken after reproducing the connect attempt.

[jjwin2k (jjwin2k)]

Yes I can reproduce this behaviour.
The problem seems to be that NM still "thinks" that the old SSID exists.

If I click on the applet after changing location I see the SSIDs of the wireless networks at my home AND the SSIDs of the networks at my workplace. The old SSIDs disappear after some time. (After NM rescans the channel ? )

I haven't looked into the NM code, but I'm guessing that NM does not clean the list of networks (per channel ?) after resume.

I attached a part of my syslog containing a typical session.

eth1 is my wlan device. (ipw2200 driver)
eth0 is my wired network device, only plugged in at home.

I start my laptop at home. (Due to upgrades for the 8.10 beta)
I connect to the wlan at home.
I hibernate the laptop.(Still connected to the wireless network)
I resume the laptop at work. There NM tries to connect to my network at home. After either timing out or l change the network by hand NM connects to the work network.
At 11:00 I hibernate the laptop at work. (Still connected to the wireless network)

I replaced the network names and login credentials by fake ones.

[Alexander Sack (asac)]

might be just a fix on NM side; however, could also turn out that wpasupplicant needs a similar fix.

[Alexander Sack (asac)]

should be filed upstream when we have verified what to do and that wpasupplicant doesnt require a similar cache flush on resume (most likely when i have the patch :))

[jjwin2k (jjwin2k)]

I'd like to add that this behaviour did not occur in hardy.
If I remember correctly, NM always needed some time to reconnect.

In intrepid the wireless reconnect after resume is much faster, but now causes the aforementioned bug.

Maybe a patch was added to reduce the reconnect time?

[Jamie Lokier (jamie-shareable)]

I have the same issue, which did not occur on Hardy.
However, it is more severe than just not clearing the cache. It seems the list is not cleared after a long time, sometimes.

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.

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.

[Alexander Sack (asac)]

Jamie, your bug is subsumed here yes. but its also a general bug, could you file a new bug with title "NM doesnt forget currently cached APs when there are zero APs in proximity".

Please drop the new bug id here for reference.

[Alexander Sack (asac)]

bug 264683 is somewhat related

[Jamie Lokier (jamie-shareable)]

Alexander, my bug is now reported as bug #292890, with the title you suggested.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Found the corresponding bug in the upstream tracker and linked it here

[Alexander Sack (asac)]

this turned out to be a driver issue; short story: drivers use jiffie to remember scan age; unfortauntely jiffies are not incremented during suspend and hence the driver doesnt invalidate the scan results properly.

[Alexander Sack (asac)]

the driver issue can be tracked in bug 336055