Posted: Wed Jun 21, 2023 1:57 Post subject: Wifi rekeying disconnection (reason 16) issue on > r49361
Recent builds after r49361 until now have an issue with wifi clients briefly disconnecting and then reconnecting a few seconds later. Client device logs show deauthentication with Reason: 16=GROUP_KEY_HANDSHAKE_TIMEOUT.
While the disruption is usually brief and handled automatically, it can cause problems with latency-sensitive applications such as voip calls.
I haven't found a cause yet despite trying various settings changes. The issue is reported on at least Netgear R7000 and Asus RT-AC68U devices.
I have tried at least half a dozen recent builds as they came out and they all have the issue, but I can confirm, as discussed in the above thread, that the issue is not present on r49361.
Last edited by fizikz on Thu Jun 22, 2023 20:11; edited 1 time in total
I already tried different key renewal intervals from the default 3600s, none of which stopped the disconnections. Disabling rekeying doesn't seem like a good idea for security, even if the risk is low. Better to solve the issue if possible.
None of the dozen or so clients here, of various brands including Intel, Realtek, LG, Samsung, Motorola, etc, achieves long connection uptimes with the affected builds, unlike with the unaffected builds, so I'm not sure it's fair to blame the clients.
Wifi settings have been discussed ad nauseam, and the bottom line is that for the *same* settings, builds before 49361 do not have this issue, and builds after consistently do.
Various settings changes have also been attempted, such as different rekeying intervals, and it has not made a difference. The *only* factor that has made any difference so far is the dd-wrt build.
If you want, I can dump all of `nvram show` as well.
As for clients, there's too many to list them all, but they are varied and none achieved long connection uptimes on builds >49361 as would typical on builds <=49361. If you want specifics, the client monitored most frequently, and which produced the deauthentication log entries I posted, has a Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter running the rtw_8822be driver.
Changed ACK timing to 1350, Auto TX power, 5GHz channel 36 LL (broadcom setting for UU) which is the only "indoor" channel for 80MHz width according to the wikipedia chart. Rekeying interval is back to 3600 because other values didn't fix the problem and larger values just take longer to test.
Tested on the current latest release 53045 and got the reason 16 deauthentication already. Going back to 49361.
A point of emphasis: this issue is specifically reason 16 group key handshake timeout, and as far as I can tell always happens at about the time of rekeying. To be clear, these aren't random wifi dropouts, which if they were, could legitimately be due to settings and environmental factors.
itwontbewe wrote:
5 GHz disconnects happen on my R7000P. i use recommend settings.
Do the logs of the disconnected clients show reason 16 group key handshake timeout, or similar explanation? If so, that would be yet another user with another device reporting this issue.
but if i change re key to 14400 any device connected will drop every 4 hrs instead of hourly
Sounds similar with the drops being at the rekeying time. By check the logs I mean check in the client device logs. The dd-wrt syslog does not show anything related for me either.
Again, for the *exact same settings* and the *same variety of clients*, the reason 16 handshake issue can *consistently* be reproduced or vanished, depending entirely on whether dd-wrt build > r49361 is used.
I really don't see how it could possibly be a settings or client issue since those are common, unchanged factors both when the issue is present and not present.
That thread indicates 5GHz wifi-related (blob?) changes were made immediately after r49361 in r49392, so that seems a possible source of the issue. Whether the root is in the blobs or not, who can say.
I suppose the only thing users can do is test again when there are further wifi-related changes, hopefully some of which address this issue.
So, I don't want to discourage finding the cause of this issue; I was affected too when I finally upgraded past the old Kong releases, with no other wifi-specific config changes. Just a note for this though:
fizikz wrote:
Disabling rekeying doesn't seem like a good idea for security, even if the risk is low. Better to solve the issue if possible.
I am not a cryptography expert, but my belief right now is that if you're not using something like WPA Enterprise where different users have different keys, there's no real benefit to rotating the group key except when changing the WPA passphrase. So for now, I disabled rotation.
The purpose of group key rotation as I understand it is that if someone leaves the group, they won't have indefinite access to traffic. But if everyone's using a shared WPA2 passphrase, there's no point until the passphrase gets changed. I looked for issues where, say, CCMP might become riskier after too much traffic with the same key and didn't find any. But again, I'm not an expert, and it'd be preferable to fix the issue.
