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
On Thursday 20 September 2007 19:20, Johannes Berg wrote:
> 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.
I still don't see how you broke scanning, at least in sta/ibss mode. As far as
I can tell, it's working fine here because you haven't removed any of the
scanning special cases which relax the rx filtering and direct probe
responses and beacons straight to the MLME during scanning. (see the
misleadingly named ieee80211_rx_h_passive_scan rx handler function)
Of course, this is with the pending-mac80211 series in mac80211-misc. Did you
break scanning in some other patches?
-Michael Wu
On Sun, 2007-09-23 at 18:31 -0400, Michael Wu wrote:
> Of course, this is with the pending-mac80211 series in mac80211-misc. Did you
> break scanning in some other patches?
Oh, of course I wouldn't post such patches; I broke scanning in later
patches when I tried optimising the frame->interface matching.
johannes