scanning implementation and sta matching

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

Looking at the code for scanning, it seems overly complicated. In fact,
I actually broke scanning and associating, but more on that later.

As for scanning, is there any reason we do it per-interface? After all,
we deny a second scan attempt on another interface when one is in
progress, and it seems not very useful to queue the frames to all the
different devices. I think we should be able to split off scanning from
the mlme implementation and I think we could benefit from that if only
because it reduces complexity of the mlme code.

Basically, I'm thinking of directing all beacons and probe responses to
some scanning queue while scanning (and probably drop all other frames)
and handle it centrally. When not scanning, of course the MLME needs to
get them to eventually be able to implement "beacon miss" etc. Do you
see any problems with that?

The other thing, why I broke it, is that I noticed that when we have
many interfaces (say VLANs) then we can end up copying frames *a lot*.
So I have patches to
 (1) make sta_info structs per-sub-if for corner cases
 (2) iterate all sta_info structs when we receive a frame from a certain
     station (instead of iterating the interfaces)

There's still a change in behaviour with this: previously we'd see
frames other stations in our BSS transmitted if (and only if) they were
clear/WEP encrypted and we were in promisc mode. By matching on the TA
we lose that, you'll only see those frames on monitors.

Maybe in some cases (toDS and "no DS bits" frames or so?) we should
match on the BSSID instead of the TA. I need to think about that more,
but it would fix that problem. WDS frames are easy, but fromDS/toDS
differ when we are an AP or a client which is a bit harder to handle.

In any case, this is how I broke scanning, we know nothing about the
stations we're scanning so the frames are directed to no interface. And
thus I came to look at the scanning code and think it would be
advantageous to separate it out from the rest of the MLME.

The other change that my approach above would require is that we add a
sta_info struct for the AP we're trying to associate to *before* sending
the first auth request frame. I don't see any problem with that but
maybe I'm missing something? wpa_supplicant as userspace MLME wouldn't
have such a requirement of course since it would use the "junk frame"
device as well.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]