On 01/29/2013 08:59 AM, Nicolas Cavallari wrote: > On 29/01/2013 12:37, Johannes Berg wrote: >> On Sat, 2013-01-26 at 13:09 +0100, Nicolas Cavallari wrote: >>> (and my take on this, is that we should just handle open system >>> authentication and reboot detection in userspace (i have code for that), >>> and revert the kernel to the old state where it would just answers an >>> open system authentication request if userspace is not handling it) >> >> 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. I agree with this statement. From my reading of the code, it seems that IBSS nodes are always authenticated. Which is fine, as long as I am not missing something! :-) > >> >> 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. > > >> 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. Totally agreed! This will not change my code at all. However, having a "new authenticated station" message (to parallel a message like NL80211_CMD_NEW_PEER_CANDIDATE from the 802.11s world) would be great too. That's how I interpreted the IBSS_STA event to work. The ultimate goal for me is to eventually incorporate SAE support for IBSS into wpa_s. In other words, I'm following this discussion very closely and I appreciate everyone's work. > > 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. > -- 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
