[RFC 0/1] libertas: new scan logic

[Holger Schurig]

> 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 other problem that I had was that I'm not able to send null 
packets to the AP. So in order to not loose the connection, I 
can only be this amount of time from the AP. By returning 
shortly back, I won't loose the association.

At least a "ping a.b.c.d" to or from the box while "iwlist eth1 
scanning" won't disassociate me with the worker logic. When I 
disable the worker logic, e.g. by 


#if 0
                /* somehow schedule the next part of the scan */
                if (chan_count &&
                    !full_scan &&
                    !priv->adapter->surpriseremoved) {
                        adapter->last_scanned_channel += to_scan;
                        cancel_delayed_work(&priv->scan_work);
                        queue_delayed_work(priv->work_thread, 
&priv->scan_work,
                                msecs_to_jiffies(300));
                        goto out;
                }
#endif

then I will be disassociated from the AP (again, while data flow 
is happening, e.g. because of a ping).

> 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.

This is what I'm currently doing in the new scan.c. Just 
let "iwevent" run while you're "iwlist eth1 scan" and while you 
monitor syslog with "lbsdebug +enter +scan".

"iwlist eth1 scan" returns almost immediately, sometimes with
"eth1      No scan results". It obviously doesn't care for the 
GIWSCAN event that I'm sending. I think it just call GIWSCAN 
followed by SIWSCAN. And that's ok so, it's the driver that 
behaves weird.

Note that once the scanning is finished (about 2 seconds later), 
I can access the result via "cat $debugfs/getscantable". So the 
scanner per-se is working, just not the transfer of the result.

To fix the behavior of "iwlist eth1 scan", I need to wait either 
in lbs_get_scan() or lbs_set_scan() until the scan-worker is 
finished. I'm just unsure about the best way this can be done, 
my kernel-foo isn't good enought. Poll until the worker thread 
is finished, wait until last_scanned_channel is 0 again, 
something like this.



> 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

I think this sucks because some scans delete the list. If I send 
several GIOWSCAN events before finished, then the longer-lived 
tool won't get the full picture of what's "in the air" for the 
first three GIOWSCAN events (assuming 14 channels and doing 4 
channels at a time).

Also, I don't know any other driver that sends several GIWSCAN 
events for one scan request. That's a second reason why I don't 
want to do something that is unusual.

> 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.

But if those programs can use the scan results as they come in, 
then they can also work with scenario 1. In fact, they must work 
with them, because this is how many other drivers work.

> 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.

Changing "iwlist" is not an option for me. I don't see it broken. 
I have used iwlist with 7 different drivers, not not observed a 
problem. It simply worked for my for several years. It's the 
driver, that can/should fix the current problem, not iwlist.

Also it would sucks to wait, say, 10 seconds, when the scan took 
only, say 2 seconds. Arbitrary timeouts are seldom good.