[RFC 0/1] libertas: new scan logic

[Dan Williams]

On Wed, 2007-11-28 at 15:49 +0100, Holger Schurig wrote:
> Hi Dan !
> 
> I've rewritten the scan logic. I'm sending this as a RFC to get 
> feedback about it.
> 
> As you see in the source, I'm not finished and have some TODOs 
> there. I've marked them with TODO in the source/patch:
> 
> 1. numprobes, channel_list
> 
> This is currently not implemented. The only code that ever can 
> set numprobes or a specific channel ist is via the 'setuserscan' 
> file in the debugfs.
> 
> I'm not aware that this is used by anybody, I'm also not aware 
> that this is terribly useful. Should I remove the code in 
> debugfs or implement the rest in scan.c to continue it's 
> support?

Unless somebody speaks up, I think this was a left-over from the iwpriv
stuff that the driver used to contain.  I'd say take it out for now, and
if people really want it we can add it back.

> 
> 2. Uncommented code
> 
> The two pieces uncommented with #if 0 ... #endif are uncommented 
> in the current version of scan.c. I don't know why. Should those 
> sections be removed or who is doing the rest of the work to fill 
> them with life?

Kill them.  They are always in git history if needed.

> 3. Mimic mac80211 bsstype
> 
> mac80211 checks for that the scan request if the proper type. 
> However, I don't see how "iwlist eth1 scan" can transfer a 
> bsstype.
> 
> Maybe some other tools used the corresponding field of the 
> SIOCSIWSCAN, I don't know.
> 
> The old scan.c didn't also support this setting.

Sounds like a good thing to support; I think it was mostly used in
wpa_supplicant or hostap or something.

> 
> 4. Allow "iwlist eth1 scan SSID"
> 
> This should probably be implemented. The old scan.c also didn't 
> support this setting, but iwconfig can do it. Maybe 
> wpa_supplicant can do it, too.

This is a very good thing to support.

> 5. Wait for the result
> 
> Both the old scan.c and my new scan.c use a worker to break the 
> scanning of 14 channels into little pieces. And both scan.c 
> versions have currently the same bug. When you run "iwlist eth1 
> scan", you'll get a result way before the scanning is finished.
> 
> What's the proper way to wait until adapter->last_scanned_channel 
> is 0 ?

This is a problem with the firmware, in that it's buffers for scan
results apparently aren't big enough to hold everything.  So you have to
break it into groups, stopping on the boundaries for 1, 6, 11 because
it's expected that more APs will be on the default channels than the
intervening ones.

The specific problem was that by breaking up the scan, and waiting 300ms
between up to 6 channel groups, made the scan latency _really_ suck.
More intelligent tools that rely on WEXT events for getting scan results
work fine because they don't care about having all the results of one
scan packaged up.  What iwconfig does is to request the scan, and poll
the card until SIOCGIWSCAN returns some results.  That's pretty dumb.
More intelligent programs like wpa_supplicant and NetworkManager are (of
course) long-lived and therefore can monitor WEXT events and build up a
smoothed scan table that the driver shouldn't really have to do.

The _ideal_ situation is that when a scan is requested, the code breaks
the scan up into sub-scans, and and tracks the progress of the _entire_
scan.  Then, the BSS list gets updated _and_ the WEXT GIWSCAN event gets
sent out after the _entire_ scan is complete, not after each sub-scan is
complete.  Whenever the BSS list changes, a GIWSCAN event should be sent
out.  So either:

1) the BSS list gets updated whenever scan results are available and a
GIWSCAN event gets sent, which is better for longer-lived tools like
NetworkManager and wpa_supplicant, or

2) The scan results are cached until the entire scan completes, then the
BSS list gets updated and the GIWSCAN event is sent, which works
short-lived tools like iwlist but sucks for programs that certainly
_can_ use the scan results as they come in, not in a batch after
(potentially) a 10 second wait.

I'm inclined to say that what iwlist should really do is to keep
gathering scan results for up to 10 seconds or until it sees an AP on
the last channel in the regulatory domain for the driver, whichever
happens first.

Dan