Re: Flush scan list on resume

[Dan Williams <dcbw redhat com>]

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