[Alozaros]

as we dont know much about your wifi settings post a pic of your R7000
wifi settings and advanced 2.4ghz settings..
for your wifi security (make sure you use wpa2 128aes only and no tkip)

de-auth could be also caused by sending a null (malicious wifi de-auth) if you have a suspicious skinny, pale skin, greasy hair with spectacles, (chips and cola diet) neighbour...

[fizikz]

[Alozaros]

im not using 5Ghz anywhere (its in my signature )
also since i sat key retaking to 14400 no drops at all..

ok i can spot few things around..

-i dont fiddle with bacon interval on broadcoms so i left mine to default same for DTIM
-i also use IP isolation, so clients dont see each other (whatever this option works) as with some apps this is not a problem..
-TX power i set to max...999 (just not happy with auto)
-on 2,4Ghz i dont use NG mixed on (broadcom) routers, use mixed instead...
-i dont use explicit or implicit beamforming...not sure this future is working well with all clients..
-same for TurboQ...clients must support it on driver level...so those are disabled..
to be honest i tested those for long time on/off and didn't see any advantage, running mixed vendor clients..
-ACK timing set to 90 is very incorrect...the lowest i used is 450, but its ok to 900 or even 3150...
-same for 5Ghz..beamforming and TurboQ along with ACK time...set it to 900
and make sure you use valid 5Ghz channels...your channels are lower lower, where it should be
52+UU upper upper

for the 5ghz radio, proper vht80 extension channel configs are:
There are only 6 possible 80Mhz blocks, so you can limit yourself to the following channels for testing purposes
36-48 36+UU
52-64 52+UU
100-112 100+UU
116-128 116+UU
132-144 132+UU
149-161 149+UU

The following should be noted:
36+UU
52+UU DFS
100+UU DFS
116+UU DFS RADAR Detection
132+UU DFS
149+UU in Europe for low range

try those setting i use, along with key 14400 and see how it goes...

[dale_gribble39]

[fizikz]

[fizikz]

Well, now it is de-authenticating at each rekeying interval. Here are some log entries from a client device:

[Alozaros]

https://community.cisco.com/t5/wireless-mobility-knowledge-base/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055

802.11 Deauth Reason Codes

16 - Group Key Handshake timeout

as this is Broadcom router and those run propriety drivers, not much you can do..try with different bacon times or longer key use i ve no problem with 14400..but...Broadcom WiFi is not the most compatible with various radio vendors and this is fact...one reason i stopped to use R7000 as an edge router..currently it serves various clients, intel, QCA, other broadcom and mediatek...i ve no issues but it seams your client is not very compatible...try to change country domain im on CANADA if this will help...also 5Ghz you must use the correct channels those are also very picky...among various clients...

give this client static IP from both sides router and client..if it helps...
or check if you have a odd character in your wifi password..no idea what else to try..

[fizikz]

Did the proprietary Broadcom drivers change since r47925? I didn't have this issue with that build, so I doubt it has to do purely with my old or new settings or the same client devices.

The client from which those logs are obtained already has a static DHCP IP. And the client wifi devices affected include a variety of brands: Realtek, Intel, LG, and I haven't confirmed yet if it happens with Samsung and Motorola/Lenovo devices.

I upgraded to r52596 and reason 16 deauthentications are still happening.

Just thinking about the stated reason of group key handshake timeout, it seems sensible to look for time-related issues or anything that could cause delays. I already use NTP on the router/AP and clients, and the update deltas in the router logs are usually very small, 0 or 1.

ChatGPT has these suggestions

[Alozaros]

ChatGPT is bollocks, try to ask him to wright you a snort script for Intrusion detection and prevention, than run it on your compliance...

If time was a factor all other platforms would be affected as NTP time is the same on all devices..vendors..its more likely either router wifi drivers or your clients..

You can try to set your NTP time, like i do ..i choose a time zone in my case London...and in
NTP time box i put those 2 IP 216.239.35.8 162.159.200.123 (google NTP time and clouflare )
just copy paste those,must be a interval between them as it is...save and apply..reboot..

I dont know any clients that will try to synch time from the router NTP time...usually they make their own requests via their NTP time servers...and NTP time on the router side its only for its own demands..no idea how those 2 will be connected...

To be honest, i dont know if Broadcom wifi drivers ware updated recently and dont follow their update...very likely those to run the last available binary..and those could be the reason...if so..

The thing is my R7000 (i use only 2,4Ghz) is ok and dont see any drops or those happen very quick and cant notice... nope i just checked my log's nothing for 2 days, so far...no idea where else to look at..
-check your static devices names doesn't contain any spaces or unhallowed characters
-try to reset and manually recompile (press reset button for 8-10 sec)

[fizikz]

NTP is already working fine on the router, AP, and clients. To be clear, the clients have their own NTP setup, I don't mean they sync with the router/AP...

Instead of playing with dozens of variables blindly, I kept them as-is and changed the one variable which was observed to make a difference: the dd-wrt version. Testing back on r47925, the client uptime is as long as the AP uptime, no reason 16 deauthentications in over 2 days so far:

[dale_gribble39]

That's not a de-authentication, that is a group rekey.

[fizikz]

[dale_gribble39]

The last time the proprietary Broadcom binary object files were updated and uploaded to the public repository. Outside of that, you'd have to look through the "automatic commit of driver changelogs" entries. Have fun.

[fizikz]

Ok, thanks for digging up that info. The released versions that straddle r49789 are r49741 (08-15-2022) and r49792 (08-20-2022).

To test the Broadcom drivers angle, I've upgraded to r49792 to see if the issue reoccurs, and if it does, I'll downgrade to r49741 to see if it goes away.

[fizikz]

Both r49792 and r49741 have had reason 16 de-authentications.

Not sure what else to try. I could either stay on known working old version like r47925 and risk security vulnerabilities, or upgrade to the latest and hope the issue gets fixed eventually.

The de-authentication events are fortunately very brief and the clients re-establish connection almost seamlessly, but I'm not sure if it could create issues for time-sensitive applications like voip or video calls.