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? I still have huge gaps in my wlan knowledge, I only drilled into the rekey issue so far and never used anything besides AP/STA... That said we only should have mesh and IBSS left to consider, right? (I think I remember some new mode allowing STAs to diretly talk to each other while beeing associated to an AP, but can't find it again and don't see how this could work with PTK keys without somehow making a mesh out of it.) So far I have avoided non-generic changes. The current patch should work with all modes, shouldn't it?. My initial impression of ieee80211_set_disassoc() was much the same, but you seem to imply it's not usable in some modes? That would again be awkward... As for IBSS: I have no idea how a mesh would handle rekeys. If it can but won't work with ieee80211_set_disassoc() it will be quite some time till I've can propose a new patch. I normally only have a few hours per week for the forseeable future, and some weeks not even those... On the plus side i got my hands on a AP using ath10k and can look at that from yet another angle. I'll devinitelly continue here, but I suspect I'll be slow with patches for a while... > >> Let's see how the supplicant will react on a disassoc while doing a rekey... > > Shouldn't matter to it, I'd think. Alexander
Attachment:
pEpkey.asc
Description: application/pgp-keys
