Kong pro firmware for IPQ806x (R7500, R7800, EA8500, ...)

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. :slight_smile:

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.