I have three Netgear R7800 routers that I use as Wireless Access Points around the house. They all run OpenWrt 22.03.5 stable builds. Since I have weird issues with ct firmware, I use the standard ath10k (non-CT) firmware on all 3 APs.
Recently I've been having an issue with 5 GHz on one of the APs. Clients will connect for less than a minute and then get kicked off and then attempt to connect to an AP that's further away.
This is etc/config/wireless and it's identical on all my R7800s. I have normal 5 GHz behaviour on the other two.
This is happening with my Galaxy S22 Ultra, an iPad Mini (5th Gen) and various Lenovo laptops with Intel AX200 or AX210 wireless cards.
System logs show the following when my laptop tries to connect to the 5GHz network:
Sun Oct 8 12:40:14 2023 daemon.info hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: authenticated
Sun Oct 8 12:40:14 2023 daemon.info hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: associated (aid 1)
Sun Oct 8 12:40:14 2023 daemon.notice hostapd: wlan0: AP-STA-CONNECTED a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:14 2023 daemon.info hostapd: wlan0: STA a4:f9:33:c6:bb:0f WPA: pairwise key handshake completed (RSN)
Sun Oct 8 12:40:14 2023 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:25 2023 daemon.info hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: disconnected due to excessive missing ACKs
Sun Oct 8 12:40:25 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:26 2023 kern.warn kernel: [845946.083094] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:27 2023 kern.warn kernel: [845947.204286] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:28 2023 kern.warn kernel: [845948.228926] ath10k_pci 0000:01:00.0: Spurious quick kickout for STA a4:f9:33:c6:bb:0f
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 12:40:30 2023 daemon.notice hostapd: wlan0: STA a4:f9:33:c6:bb:0f IEEE 802.11: did not acknowledge authentication response
It's a little different for the Galaxy S22 Ultra which doesn't connect at all:
Sun Oct 8 16:34:09 2023 daemon.notice hostapd: wlan0: STA 44:ea:30:c6:32:1d IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 16:34:18 2023 daemon.notice hostapd: wlan0: STA 44:ea:30:c6:32:1d IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 16:34:18 2023 daemon.notice hostapd: wlan0: STA 44:ea:30:c6:32:1d IEEE 802.11: did not acknowledge authentication response
Sun Oct 8 16:35:04 2023 daemon.notice hostapd: wlan0: STA 44:ea:30:c6:32:1d IEEE 802.11: did not acknowledge authentication response
Is this a hardware fault with one of my R7800s or is there something more to it? Any way I can diagnose and get more detailed logs as to why none of my clients can maintain a connection on 5GHz with this particular AP?
How many clients are there in total? This looks like a firmware limitation. To work around it, please try the ct driver with the ct-htt (not the plain ct!) firmware. Also, you need to create files that allow one to increase the number of connected clients (this setting is tunable on ct builds).
Probably not a firmware limitation. I use the non-ct firmware and this is what I get. (Everything default, although I am on SNAPSHOT)
iw list | grep -i maximum
Maximum associated stations in AP mode: 512
I would use channels 36-48, and not 149. Depending on your country setting, channel 149 tx power is very weak, as strong, or stronger. But even then it's not as compatible as 36-48.
Could be other things as well, but I'd try to change the channel before anything else.
Nowhere near 32 clients. Only about 6 clients using 5GHz normally, and only 2-3 of those at the same time. 10-15 clients on 2.4GHz which are unaffected.
root@H80-R7800-1:~# iw list | grep -i maximum
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
* maximum A-MSDU length
Maximum associated stations in AP mode: 512
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
* maximum A-MSDU length
Maximum associated stations in AP mode: 512
Due to a stupid regulatory limitation in my country, Android phones (that presumably rely on linux's wireless-regdb) can not see any 5GHz APs if they are set to anything lower than Ch149.
I'll live without it on my phone, Apple devices and Windows PCs can see other channels (including Channel 36), so I'll change the channel on that particular AP and see if I get the same behaviour.
I don't need high Tx power anyway, all of my APs are set to 20 dBm for 5GHz.
Management frames have never proven to be a problem before on any other APs or with any of my clients, but I'll try disabling it and changing to Ch36 and see if it makes a difference.
Made the following changes and did some quick testing.
Switch to Channel 36
Disable 802.11w (management frames)
Got stability, at the cost of performance. Clients won't disconnect immediately, but performance is underwhelming and far below what I typically get on my other R7800s set to Channel 149.
Despite sitting 5 feet away from the AP, Windows reports one bar less than full signal strength. Something to do with signal quality perhaps?
In the image below, Tx Rate briefly increased to 390 Mbit with 80 MHz channel width, but it remained on 40 MHz for majority of the time.
No reason for those low speeds. But I have no obvious tips. My R7800 are in a mesh with 1300mbs linkspeed. And on the same channel I mye private og guest wifis too.
I also read something about Android phones will change wireless-db when they connect to mobile network, so if you’re on airplane mode you might be able to use lower channels. (Not that it really helps, other than to know the reason why, and why it doesnt happen with iPhones)
I've tested with a foreign SIM card from a place where Channel 36 is allowed according to wireless-regdb and I can see 5GHz networks on those channels.
The moment I remove the SIM card, the network disappears. If I insert a SIM card from the country I'm in, same thing. Nothing below Channel 149 will show up in the list of available networks.
So far the AP is working with Channel 36, nobody is being kicked off, but performance is crap. Ran a few iPerf tests and transfer speeds will occasionally drop below 100 Mbit as well, terrible for 5GHz.
I can easily hit 450+ transfer speeds on Ch149 with the other APs. Just can't figure out why 149 stopped working on this AP all of a sudden.
with any of these things I find the most likely thing to fail is the power supply
if you have a few try swapping around the power supply's
this is even more likely if you have USB devices attached
also try lowing the power output
even more problematic in you have metal close by
as I have seen people putting ap's in tin sheds & mounting them next to the tin wall
when the power goes up it reflex back with all sorts of problems
Super close to taking a sledgehammer to this piece of junk. No matter what I try, nothing works.
Tried @Lucky1 suggestion and swapped the power supply with one of my other working R7800s.
No change. In fact performance has become worse, so much so that iPerf refused to go above 20 Mbit/s while I was sitting on a chair right next to the AP, kept switching between Channel 36 and 149 to see if that made a difference, and it did not. The connection is stable now, none of the clients are getting kicked off, but the performance is absolutely horrendous.
Is there any way to get more detailed logs or information from the AP to figure out why clients are connecting at low link rates and only 40 MHz channel width?
you have probably done this
but double check the back hall LAN cable
end of the day if you have swapped around 2 units
and the channels they where on
and the problem stay with the one unit
well seems like that unit is now faulty
