Re: Flush scan list on resume

[Dan Williams <dcbw redhat com>]

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