Try increasing "station inactivity limit" in each wireless interface ...
Network->wireless-> [interface config] interface settings's advanced settings tab ... the 2nd "advanced settings" tab on each interface's config page (!)
I picked 3000 seconds and my misbehaving device stays connected.
Mmmv,
M.
Unfortunately it didn't work.
I even went back to an old version I had around that used to work, but looks like it keeps using the problematic driver? I'm on KONG 22 r20104-5528b5eb93 / LuCI branch git-22.288.45147-96ec0cd.
Log shows hundreds of occurrences of:
Jun 8 16:05:03 OpenWrt hostapd: wlan1: STA 8e:85:80:0a:e4:9a IEEE 802.11: authenticated
Jun 8 16:05:03 OpenWrt hostapd: wlan1: STA 8e:85:80:0a:e4:9a IEEE 802.11: associated (aid 3)
Jun 8 16:05:12 OpenWrt hostapd: wlan1: STA 8e:85:80:0a:e4:9a IEEE 802.11: deauthenticated due to local deauth request
Jun 8 16:05:19 OpenWrt hostapd: wlan1: STA b8:2d:28:1b:ef:1c IEEE 802.11: authenticated
Jun 8 16:05:19 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 IEEE 802.11: authenticated
Jun 8 16:05:35 OpenWrt hostapd: wlan1: STA b8:2d:28:1b:ef:1c IEEE 802.11: did not acknowledge authentication response
Jun 8 16:05:35 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:96:4f IEEE 802.11: authenticated
Jun 8 16:05:38 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:96:4f IEEE 802.11: authenticated
Jun 8 16:05:56 OpenWrt igmpproxy[4565]: MRT_DEL_MFC; Errno(2): No such file or directory
Jun 8 16:06:00 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:96:4f IEEE 802.11: authenticated
Jun 8 16:06:00 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:96:4f IEEE 802.11: associated (aid 3)
Jun 8 16:06:03 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 IEEE 802.11: authenticated
Jun 8 16:06:03 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 IEEE 802.11: associated (aid 4)
Jun 8 16:06:05 OpenWrt hostapd: wlan1: AP-STA-CONNECTED 78:0f:77:fd:83:66
Jun 8 16:06:05 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 RADIUS: starting accounting session 98F5F94467AD77BF
Jun 8 16:06:05 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 WPA: pairwise key handshake completed (RSN)
Jun 8 16:06:05 OpenWrt hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED 78:0f:77:fd:83:66
Jun 8 16:06:26 OpenWrt hostapd: wlan1: AP-STA-DISCONNECTED b4:8a:0a:c5:3d:30
Jun 8 16:06:26 OpenWrt hostapd: wlan1: STA b4:8a:0a:c5:3d:30 IEEE 802.11: authenticated
Jun 8 16:06:31 OpenWrt hostapd: wlan1: AP-STA-DISCONNECTED 78:0f:77:fd:83:66
Jun 8 16:06:33 OpenWrt hostapd: wlan1: STA 78:0f:77:fd:83:66 IEEE 802.11: did not acknowledge authentication response
Jun 8 16:06:38 OpenWrt igmpproxy[4565]: MRT_DEL_MFC; Errno(2): No such file or directory
Jun 8 16:06:42 OpenWrt hostapd: wlan1: STA 8e:85:80:0a:e4:9a IEEE 802.11: authenticated
Jun 8 16:06:42 OpenWrt hostapd: wlan1: STA 8e:85:80:0a:e4:9a IEEE 802.11: associated (aid 1)
Jun 8 16:06:43 OpenWrt hostapd: wlan1: STA c8:2b:96:04:bd:1a IEEE 802.11: did not acknowledge authentication response
Even reverting to stock firmware makes those 2.4ghz clients disconnect every other minute. I'm clueless right now.
One rogue client can bring a network down see if the logs identify a rogue client otherwise disable all and bring those on line one by one.
Furthermore use a traffic analyzer to see if there is interference from other networks
A stable build? Try the last 21.x build by hnyman. It's been a decent balance between stability and speed for me. Though you may need to use the startup commands to configure the governors.
As I've stated before, problem is happening on v21, 22 and 23, it gets worse after a few hours. All I can relate to is this topic:
Ath10k: the dreadful bug "deauthenticated due to inactivity (timer DEAUTH/REMOVE)" - Installing and Using OpenWrt - OpenWrt Forum
@the4anoni mentioned that going back to v19 fixed all issues. I will try that and report back.
Edit1: didn't work, had all 2.4ghz randomly disconnecting. I've unplugged each client and went connecting one by one. They all work fine until the driver starts to pop errors. Went back to 23.05 and the same happened. This is what kernel log shows:
Sun Jun 9 16:06:11 2024 kern.info kernel: [ 711.998838] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.058720] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.208711] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.348699] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.478700] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.608738] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sun Jun 9 16:06:12 2024 kern.info kernel: [ 712.617682] ath10k_pci 0001:01:00.0: mac flush null vif, drop 0 queues 0xffff
Do I understand correctly that you're removing the ath10k-ct driver each time and replacing it with ath10k?
I'm changing to another firmware with non ct drivers.
So yesterday night I was messing with 2.4G settings again and changed from channel 11 to channel 6. Suddenly all started working flawlessly. All clients connected without asking for DHCP leases every 20 seconds. I went to sleep with 0 log errors for more than 6 hours. Woke up today and all clients were disconnected, thousands of lines of log errors and 0 clues on WTF is going on. 
Since you have already tried a few builds and still have some strange behavior, that your logs don't explain. I would check if something in your environment changed.
I once had a user that had drops and throughput issues. His issues were caused by a bluetooth headset. I don't recall the brand, but it was advertised as low latency bluetooth headset, which did not follow bluetooth spec. Bluetooth also sends in 2.4Ghz. Also had a realtek client device with wifi/bluetooth combo chip there was a bug in the bluetooth part that caused drops for this client.
2.4ghz protocols are hopelessly outdated. They came from a time of far lesser WiFi signal saturation, and have poor cross-signal mitigation methods, which is why in a typical multi-apartment building your TV will choke trying to stream something over 2.4ghz, unless you put the router right next to it.
5ghz protocols don't have the same problem. I would suggest migrating every device possible to 5ghz.
Just for testing I hooked up an Asus AC87U I had here. Using the same channel/SSID/configs and everything has been stable for the past 18+ hours.
I suspect there is an issue with my R7800. I am considering reflashing the OEM firmware for additional troubleshooting.
I've currently got a R7800 running DD-WRT, its running well, but with the release of kernel 6 SFE (which is needed for 1gig broadband) is hit and miss, and the introduction of NSS-SFE is still giving me issues with random reboots.
What is the current state of OpenWrt on the R7800? Is it more stable than DD-WRT? Will I get 900+Mbps? Is the WIFI speed good?
(PS: I'd love to go back to running Kong firmwares, he is a legend from his days working with DD-WRT).
Nothing beats DDWRT on K4.9 but alas that is EOL.
OpenWRT Stable (K5.15) is very stable and can give you 600 Mb/s WAN<>LAN without any off loading
If you need 1 Gb/s WAN<>LAN then this NSS build is the way to go.
The last update for Kong's NSS build was 1st June.
Would there be any security issues to address since then - eg Openssh - or still all ok?
Not sure, OpenWRT standard uses Dropbear which is not a problem, not sure what Kong has, but knowing Kong it should be safe, otherwise he would have made amendments
I have bought a 2 port USB relay board with a CH340 chipset. It is detected by the usb system as a generic device but it is not accessible by a COM port. It might be because kmod-usb-serial-ch341 kernel package is not in the Kong's repository (I already have kmod-usb-serial package installed). I am unable to access the relay (using a python script). Is it possible to add support for the CH340/1 based usb-serial adapters to Kong's repository?
Thanks
Just compile your own build and you can add (or remove) any package you want.
I have recently done this mostly to remove packages.
Kong added everything but the kitchen sink ( and except kmod-usb-serial-ch341 apparently )
I believe his build are optimized for IPQ806x based routers. Is this not so?
This thread is called:
Kong pro firmware for IPQ806x (R7500, R7800, EA8500, ...)
I think that tells it all
I want to try to build the kernel module kmod-usb-serial-ch341. I have looked at the instructions in https://openwrt.org/docs/guide-developer/toolchain/single.package. Should I clone the main branch or the development branch?
Thanks
Updated Netgear XR500 NSS yesterday, keeping all settings.
All went well.
The only thing I've noticed is that 5GHz wireless shows Bitrate maxing out at 433Mbps where before it was over 700.
My clients seem to connect faster than 433 - laptop at 867 for instance, regadless of 433 max reported.