On Wed, 2009-02-04 at 18:04 -0500, Tony Espy wrote: > Dan Williams wrote: > > 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). > > How 'bout getting drivers to add code to their resume functions that > just clears the scan results queue?
That's not desirable on mobile platforms like OLPC that do suspend/resume very quickly and very often. The best mechanism is to make the *actual* last seen time available to the userspace programs that implement the policy (like connection managers) so they can do what's appropriate. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
