Re: [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response

[Johannes Berg <johannes@sipsolutions.net>]

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