Soon after clicking send I believe I figured this out. I had been rekeying by sending REKEY_GTK then immediately sending REKEY_PTK. This actually caused a GTK only rekey, then a PTK + GTK rekey. I still think there is some race in hostapd since it apparently did not install the second GTK key, hence I lost broadcast. Its unlikely but I still think this this could cause problems. For example: A station leaves causing a GTK rekey. Then a station rekey timer happens to fire immediately after causing a rekey for that station (PTK + GTK). This may cause the same behavior I am seeing, but hard to know for sure. On Fri, 2021-10-01 at 13:17 -0700, James Prestwood wrote: > Hi, > > While implementing extended key IDs for IWD I ran into this problem > where a second set of rekeys (PTK + GTK) ended up losing broadcast > traffic. Figuring it was a bug in my code I tried the same setup with > wpa_supplicant + hostapd and ran into the exact same behavior. > > Monitoring NL80211 I can see there isn't much difference between my > implementation and wpa_supplicant, in short both do the following: > > - Parse the extended key ID KDE from message 3 > - Use NEW_KEY with an RX only flag > - Send message 4 > - Use SET_KEY with TX enable flag > > The kernel is happy with this, and the first rekey does in fact work. > But when I rekey again I lose broadcast. One thing to note is that if > I > only rekey the PTK I can do this many times (I tried 10 in a row). > > One thing I noticed is that the PTK key ID toggles between 0 and 1, > and > the GTK key ID toggles between 1 and 2. They are never the same value > at the same time, of course. I'm thinking the kernel has the old PTK > and is using that instead of the GTK since the indexes (1) overlap. > > I can send logs upon request, but large messages need approval and in > the past I haven't had much luck with that. > > Thanks, > James > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
