Hi Alexander,
hostapd or wpa_supplicant are "ordering" mac80211 to install a new key
and are implementing the state machine and are in a good position to
handle the fallout... at least theoretically.
Ideally it would even know beforehand that we don't want to handle the
PTK rekeying, and then could reconnect instead of going through the
handshake.
Don't see how we could do that in the kernel, all the relevant
information is handled in the state machine. I guess an API extension
telling hostap/supplicant if we can handle rekeys or not would tbe he
only way to avoid that.
Can the kernel / driver provide some sort of hint to user space that PTK
rekey isn’t supported? We could then have user space deauthenticate
with a big warning about what/why this is happening and try to
re-connect to the last used BSS.
So I think we're probably better off accepting the set_key but not
actually using it, and instead disconnecting... even if that's awkward
and should come with a big comment :-)
Instead of returning an error I'll change the code to accept the rekey
but do nothing with it. (Basically delete the new key and keep the old
active).
And of course calling ieee80211_set_disassoc() prior to return "success".
Let's see how the supplicant will react on a disassoc while doing a rekey...
This sounds pretty awful actually. Now that wpa_s is not the only game
in town, can we stop resorting to these tactics?
Regards,
-Denis
