>>> 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. > I'll try that, but will probably take another week. My main main work station got severe file system corruption, forcing me to reinstall it from scratch. I suspect it was something in the wireless testing kernel 4.18-rc1 (944ae08d4e71) related to either btrfs or the ssd disk but since I needed the system just started over and avoid to run 4.18 if I do not have a full backup... >> 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. >> 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 :-) 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... Alexander
Attachment:
pEpkey.asc
Description: application/pgp-keys
