No broadcast after 2nd rekey using extended key IDs
prestwoj at gmail.com
Fri Oct 1 13:53:44 PDT 2021
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
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
On Fri, 2021-10-01 at 13:17 -0700, James Prestwood wrote:
> 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
> 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,
> 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.
More information about the Hostap