On Tue, 2009-04-21 at 23:41 +0300, Jouni Malinen wrote: > > 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 ... > > wpa_supplicant happens to know the SSID at that point and adding SSID to > authentication data helped in implementing some steps for > authentication. Since SSID is not strictly speaking required for > authentication, I did not make it a required attribute. However, I do > not have anything against making this attribute required for > authentication (maybe with a suitable note in nl80211.h indicating why > it is required since that may be somewhat surprising requirement for > someone familiar with the MLME primitives). Alright. Yes, the MLME primitive doesn't include it so I agree it needs a note on why it is needed (or at least _that_), but I can't see anyone ever wanting to auth with a network they don't know the SSID for yet... > > 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? > > I would say that SME should keep track of this regardless of whether we > internally have that information or not. As such, I would not consider > this mechanism essential (but sure, if we ever end up adding the STA > entry at this point, its authentication status should be available at > least in debugfs). Ok. > > 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? > > Which part here do you consider to be "stupid"? ;-) Authenticating with > multiple APs? I think it would be perfectly fine for the SME to try to > do this and the AP that deauthenticated the STA would just reply with a > deauthentication frame (which needs to be reported to the SME). Anyway, > I would expect a common implementation of SME to request authentication > just before the association in all cases even if a previous > authentication might exist. Well, say the SMe tries to assoc with an AP it authenticated with ... 15 minutes ago. I suppose it just has to be prepared to get "no sorry", so it's not really all _that_ stupid. > > 4) When we try to authenticate while associated (FT-over-the-air), we > > need to turn off powersaving, I think? > > It depends on what exactly you mean with power saving.. Especially, if > we were to support FT resource reservation protocol at some point, it > would be reasonable to expect the STA to go to power save mode with the > current (old) AP prior to starting FT over-the-air with the target AP. > If the authentication (FT resource reservation) fails, the STA may still > continue to use the association with the old AP. > > As far as power save state with the new AP is concerned, yes, we will > need to remain awake to receive the authentication frame from the AP. I was only thinking of the last bit -- to receive auth frames. This will be fun in mac80211, but is related to what I said before, I don't think FT from an AP to another can work properly right now, _especially_ not if the second AP denies the association. > > 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? > > I think I would be fine keeping this simple and just make this > automatically configured in the driver and not bother with making this > discoverable. Trying the same frame three times does not make much point > in most cases, i.e., one attempt (at least if a reply is received) > should be enough.. > > > b) there be an event when reached? > > Yes, that sounds like a good idea. I keep getting bitten by it so I really have an interest in that ;) For wext we currently send "disassoc" or whatever, but I suppose a new event would be better here. > > 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? > > I did not yet implement proper handling for the case where multiple auth > algs are enabled. SME should interpret the non-zero status code and > figure otu that it need to try another authentication algorithm. Ok. Just wondering really -- cfg80211's wext SME will need that too. > > 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. > > Since SME has it, it was simple to just pass it in. I don't know whether > it would really ever be required. This is partly from the design where a > single connect request could be used (the alternative for supporting > drivers that do not support separate authentication and association > step) and it would be useful to have all the needed information > available. Wrt. connect() request, I don't think it should use the assoc() command, but that remains to be seen (of course, I know somebody who would vehemently argue that not using it would be MSDOS) -- the thing is that I would like to be able to validate the assoc() command in cfg80211 against the AP that we authenticated with. > > 9) Disassoc should check that we are associated, deauth is more > > complicated because of multiple authentications, cf. 3), do we care > > about auth? > > Hmm.. There could be potential problems if the AP and STA get > out-of-sync on auth or assoc state and we prevent the SME from sending > out a deauthentication frame which could otherwise be used as a way to > clean up the state in the AP (until 802.11w comes into play ;-). I > wouldn't be concerned if we do not verify the state for deauthentication > (or even for disassociation, for that matter). Good point. I need to think more about how to keep track of things in cfg80211 wrt. auth/assoc states. > > 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) > > OK, sounds reasonable (and yes, please do restrict it to the channel, > too, if known ;-). Yeah, if known -- well, requested from the SME. Of course, if we just require a channel we always know it ;) OTOH, the wext SME in cfg80211 is related to this and doesn't always have a channel so maybe not worth requiring one in nl80211. > > 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. > > Signal strength should be updated for all entries with matching BSSID > and same probably for other radio parameters (WMM changes, HT, quiet > period, etc.). The parameters that are likely to be specific to an > SSID (security configuration like WPA/RSN IE) should not be updated if > there is not a matching SSID. The question is how to really know what can be updated and not :) Especially wrt. the IEs I think we probably should add another way to pass this information to userspace, especially when we add API to register interest in beacon changes. By that, I mean that somehow the SME can say "I need changes in IE 42" [whatever that is] and we program the hardware that way. But then we want an event when that actually happens... Not really sure yet, but I have a feeling that scan results aren't necessarily the best way. OTOH, we could just unilaterally send a BSS struct to the application. Maybe we should have both entries present, the one with the nulled-out SSID and the one with the proper SSID from probe responses and have the SME stitch it together? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
