On Tue, 2013-01-29 at 14:59 +0100, Nicolas Cavallari wrote: > > I think that would make sense. However, to really implement that it > > seems that wpa_s should be able to control the in-kernel station > > "authenticated" state, not just "authorized" state? > > Theoritically, yes. However, i don't remember that the "authenticated" state actually > changes anything in IBSS mode. In fact, with the current code, all stations have the > "authenticated" state, whatever the specified parameters and even when the kernel > initiates an open system authentication. Good point, so there's not really a reason to manage this at all. > > What's the status we have today in the kernel, without the patches, and > > what would that "revert" mean? > > Right now, all IBSS stations have the "authenticated" flag. > > If userspace is subscribed to auth frames, userspace have to handle everything, else, if > userspace is not subscribing to auth frames: > - When detecting a new station, the kernel sends an open system auth request, as part of > node reboot detection. > - When the kernel receives an open system authentication request, it destroys the station > and recreates it as part of node reboot detection. If all goes well, it answers it. > - wpasupplicant uses the NEW_STA and DEL_STA events to maintain a list of stations. It > starts RSN handshakes on NEW_STA, and destroy its state on DEL_STA. Eventually, if > handshakes succeeds, wpasupp authorize the stations with SET_STA (i think). much older > wpasupplicant do not support authorizing stations, so the kernel always authorize stations > (but all their unencrypted frames will be dropped until wpasupp configures a PTK after a > successful handshake). > > The revert is just my personal taste, but in the case where userspace does not subscribe > to auth frames, i would just make the kernel answer an open system authentication request > if it receives one, and not send any open system auth by itself. That would mean no reboot > detection unless userspace does it. wpasupplicant would maybe need a way to reset the > kernel's sta_info if not already possible. That seems reasonable. Actually there's no reason for wpa_s to "reset the [...] sta_info", all it really has to do is set it to unauthorized if it detects it was rebooted, and then start key negotiation again, I think? > > What changes could we make today to solve this in a way that's > > compatible with today's wpa_supplicant (and maybe Will's SAE > > implementation, though maybe he wouldn't mind small changes too much)? > > Will's SAE will not be affected by any of this, as it's done in userspace by subscribing > to auth frames. If Will need node reboot detection, he has to do it himself. Makes sense. > If we want a working node reboot detection with the current wpasupplicant, we need, in > IBSS mode, to only make the kernel send NEW_STA when a station is authenticated. There's > not much choice here. > > If it's acceptable to not have node reboot detection with current wpasupplicant, we could > make a future wpasupplicant add a flag saying it supports the new IBSS_STA event, and the > kernel would only do reboot detection in this case. I think that's acceptable, but if it requires a wpa_s change anyway we could just implement reboot detection there instead of adding all these new events etc.? I.e. rather than having a new supplicant say "OK I will listen to the right event when handling reboot detection", it could just use the existing infrastructure and implement it itself? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
