On Wed, 2009-02-04 at 12:45 -0500, Dan Williams wrote: > On Tue, 2009-02-03 at 22:38 -0800, Howard Chu wrote: > > I haven't gone looking for this in the code yet, does NM get a DBUS event > > on > > standby/suspend and/or resume? It would be nice if it would flush its AP > > list > > at (one of) these points. I frequently set my laptop to sleep before going > > elsewhere; when I wake up its scan list shows all the APs in the new > > location > > but it also still shows the AP I was last associated with (even though it's > > not in the present location) and tries (fruitlessly) to reassociate with > > it. > > It should just forget the old info and only use the new scan results. > > It does flush the scan list [1]. I looked into this a long time ago > (should probably do so again), and the actual problem wasn't in NM, but > in the supplicant or the driver, which had results left over from before > the suspend. NM got those results when requesting the latest results > from the supplicant. That's not to say that we can't do something fun > with "last_beacon" IE of the results, if we can get that from the > supplicant.
So here's why old access points show up after resume... Executive summary: exclusively a *driver* problem Detailed explanation: Most kernel drivers use 'jiffies' as the timestamp for each scan result. jiffies is a kernel counter that counts *while the kernel is alive*, and thus does not reflect time spent in suspend and hibernate. When the supplicant requests scan results from the driver on resume, the supplicant (and NM) gets back a list of scan results with recent-looking timestamps that do not reflect the time the machine was suspended. The solutions are to move drivers to using the actual machine clock (the kernel equivalent of time(2)) for last_beacon, or to be more agressive about expiring entries on resume with something like (10 - time spent in sleep). A temporary workaround in the supplicant would be to push the last beacon times up to NetworkManager, and have NetworkManager ignore any AP which was last seen before NM was told to wake up. This doesn't fix it completely though, since any AP seen just before sleeping wouldn't be ignored, even if it was miles away from your present location. Worse, the AP you were connected to before suspending is more likely to have a smaller "last seen" than other APs. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
