Hi, > 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... Ouch. FWIW, it's possible to run inside a VM with PCI(e) devices outside, at least on some machines. > > > 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. Right. Not really much point for now I guess. > > 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". Right. Did you handle/consider modes other than BSS/P2P client btw? > Let's see how the supplicant will react on a disassoc while doing a rekey... Shouldn't matter to it, I'd think. johannes
