Hi,
I have a couple of questions, and maybe some notes.
1) I think I've asked this before but don't remember the answer, why
does nl80211 not require an SSID for AUTH? It seems wpa_supplicant's
sme.c always requires an SSID, so we would always have one in the
kernel -- and it would seem to be easier to implement it all too.
Also, it seems very strange things might happen if the SSID isn't
passed and the kernel somehow knows, from a previous scan, about a
hidden SSID that was unwanted, but now gets selected?! Can we just
require the SSID?
I know technically we don't need it, we could auth with multi-SSID
network's AP and only at assoc time select the SSID, but ...
2) We need a way to query which AP(s) we're authenticated with -- we
should have association too but that you can get via the station
code. But for authentications we don't add any station structs. Or do
we not care and say that the SME needs to keep track?
3) Related to 2), when we authenticate with two or more APs, but then go
to associate with one of them, which is possible to request in the
current API, we might never know, due to powersaving features,
whether the other APs deauthenticated us. Can we rely on the SME not
doing stupid things like that?
4) When we try to authenticate while associated (FT-over-the-air), we
need to turn off powersaving, I think?
5) Like 1) and the SSID, the SME always knows about the channel too;
should we also require that? Might make things simpler, and not
require scanning in the kernel?
6) The sme.c code contains a TODO about timeout -- mac80211 gives up
authenticating when it doesn't get a reply to the frame after three
times. Should
a) those retries be configurable or at least discoverable, maybe
some devices do not support configuration, or maybe both?
b) there be an event when reached?
If neither then we are in a situation where we don't know that the
device/mac80211 has stopped trying. Or the device is still trying but
we've given up in the SME.
7) Your SME code never tries to use a different authentication algorithm
if the first one failed? Is that correct or could networks use LEAP
_or_ OPEN?
8) The associate command takes a channel -- is that required? It seems
that once you've authenticated you pretty much know that already, or
do we need the SSID/BSSID/Channel to uniquely determine the BSS? The
corresponding mac80211 code ignores it completely too.
9) Disassoc should check that we are associated, deauth is more
complicated because of multiple authentications, cf. 3), do we care
about auth?
Ok... Now thoughts on how I'd like to implement the cfg80211 SME.
10) I would like the cfg80211 auth/assoc ops to take cfg80211_bss
structs. This requires having the SSID -- see 1). It would mean
cfg80211 could hold the BSS and keep a pointer, also fixing that
"hidden SSID scan result hold forever" issue. Also, it would mean
that cfg80211 has to issue a scan when it cannot find the BSS, but
that scan can be restricted to the SSID (and possibly the channel)
11) Since now cfg80211 keeps track of auth/assoc, we need a "I've given
up" call from the driver, cf. 6), so it can unhold the BSS struct.
12) Beacon updates could update all BSS structs we know about that have
the same BSSID (and channel?) -- also the one we're holding, just in
case we are connected to a hidden network. Not quite sure yet how to
do this though, the SSID might disappear then or something... Needs
more thought.
13) For WEXT, just do most things in cfg80211.
This would reduce mac80211's mlme to just filling and sending the
frames, and filtering the responses, I think. And doing all the other
stuff inbetween, of course.
Ok, let me give you some time to digest this :P
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
