Re: [RFC] Make scan mode configurable

[Daniel Wagner <wagi monom org>]

On Tue, Feb 10, 2009 at 11:24:23AM -0500, Dan Williams wrote:
> On Tue, 2009-02-10 at 08:50 +0100, Daniel Wagner wrote:
> > This adds support for continuously scanning. Also it alows to specify
> > the scan inteval and the pruning time at runtime.
> 
> Ideally, nobody should have to touch internal scan details.  

Yeah, I think we all agree on that.

> The reason
> people keep wanting to is a combination of issues in drivers, the
> supplicant, and NetworkManager itself.
> 
> * kernel drivers
>     - Many drivers can't do specific-SSID scans (airo and out-of-tree
>           drivers mainly)
>     - Drivers don't always honor specific-SSID scans; with iwlwifi and
>           hardware scanning, errors aren't returned to userspace so NM
>           doesn't know when requested scans can't be performed.
>     - Not all drivers report last beacon times
> 
> * WEXT
>     - Cannot adequately report errors from most operations

I expect that Johannes's scan API patches for cfg80211 should soon be 
available (in wireless-testing). I guess it isn't worth spending time 
on WEXT.

> * wpa_supplicant
>     - D-Bus interface can't take specific SSIDs to scan
> 
> * NetworkManager
>     - Doesn't have a good mechanism to report when users want better
>           scan information
>     - Scan backoff algorithm needs to be optimized
>     - There could be bugs in the pruning algorithm
> 

Thanks for this list. As I see there is a lot of things to work on :)

Could you tell me what you have in mind on how NM can report better scan
information?

> Obviously, the main problem is that not every AP is reported in each
> scan, which is partially the fault of the drivers for not supporting
> specific-SSID and active scans, and partly just wireless being
> unreliable by definition.  This is what kills continuous scanning which
> throws away the AP list each scan.  Sometimes your AP will be there,
> sometimes it won't, depending on whether somebody turned on a microwave
> during the scan.  You really do need some meta-tracking of scan results
> across scans.

Indeed some sort of filtering is needed. 

> There's a few things we can do, patches for them gratefully accepted:
> 
> - Scan more often when not associated to anything, which helps your case

As I understand this will help when we don't have a connection so far. The 
other case (disappearing AP) could be solved when we get some information
from the drivers that we missed beacons. And then we could start again
we more agressive scanning. 

> - If the scan list changes substantially (in a car, on the train, etc)
> across a few scans, make the prune interval smaller.  ie, if AP turnover
> is > 50% in two successive scans, be more aggressive about dropping
> older APs.  This would work much better in combination with 

Yes that sounds like the logical next thing to get working.

> - 0.6 had a mechanism for the applet to notify NetworkManager that the
> user was actively interested in the network status; each time the menu
> was pulled down, the applet would tell NM, and NM would assume the user
> was interested in the network topology, and decrease the scan interval,
> or perform an immediate scan if one hadn't been done recently.  Ideally
> this would take the form of a new signal of the
> org.freedesktop.NetworkManagerSettings interface for "UserActivity" (or
> some better name) that NM would listen for.

Well, I'm currently not really interested in the applet but who knows, if
the fruits are hanging low I can work on that too :)

> Any of these sound interesting to you?

Sure, I think I will start with NM and then dig deeper. So I start with
looking at the backup algorithm and the pruning.

thanks,
daniel