On Tue, 2018-07-03 at 21:54 +0200, Alexander Wetzel wrote: > > I think easier would be to just disconnect ourselves? At least if we're > > in managed mode... > > > > I still have much to learn about 802.11, but so far I did not see way to > directly disconnect a STA. (Maybe spoofing a "signal lost" event or > something like that, but I fear complications by losing the sync with > the remote STA.) Is there any call/signal you have in mind I could test? ieee80211_set_disassoc(), this can also send a frame out to indicate to the AP that we're disconnecting instead. > 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. > Instead I get a pop up asking for the PSK. Entering it reconnects > normally. Cancel the prompt disconnect till a manual reconnect. > I suspect NetworkManager is handling the rekey like the initial key > install and then assumes the PSK is wrong. Hardly surprising but also > highly visible to the users. That's pretty awkward. > But then only to those using the now broken rekey... Yeah, but you don't necessarily control that - i.e. client device and AP might have different owners :-) > Using wpa_supplicant directly reconnects after ~15s. > It also assumes the key is wrong and seems to rate limit the connection > attempts. Here a log with wpa_supplicat running in the console and dmesg > -wT output on top of that: 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 :-) johannes
