I'm operating 2 TP-Link Archer C6 V2 with Openwrt. 1 of them is a dumb AP. I switched to this setup in the first place because the router of my ISP couldn't handle to much connected devices via WiFi. It is now in bridge mode and this setup has been working well so far.
Now that more devices are being added to the network the connectivity got unreliable. Only a restart helps and I'm suspecting that the Archers cannot handle the amount of active DCHP leases.
Could this be the reason? What can I try?
I'm a beginner and don't know too much about this topic. Please bear with me and I kindly ask you to explain things to me as simple as possible. Like to a toddler or something
Appreciate your help!
Counting 16 leases but that can't be too much can it?
Is there any way to find out what is causing these network connection errors?
16 isn't a lot.
Does the connection to internet die completely, or just for the wireless devices?
Which openwrt version are you using?
If I remember right dnsmasq can handle 100 or 150leases, not sure if it was 100 or 150 but from 16 the system have a lot more room left before being full.
dnsmasq surely can handle more than that it is just a question of memory. So to avoid DoS attacks the default is 150.
Thank you for all the replies.
I don't think it dies because wired devices are fine. I can see on one of my smart devices and on one of my phones that there are disconnections logged regularly. First I thought these are downtimes of my ISP but I'm doubting it because the WiFi connection problems are throughout the day. Lan connections are staying online all the time.
This is a known problem with the ath10k-ct wireless drivers that are optimised for devices with limited resources and only support a small number of station connections.
The answer is to remove all the ath10-ct packages and replace with the non-ct versions.
Then you should be able to connect hundreds of stations if you have enough free ram. (You have a total of 128MB so should be fine)
Ah yes I found it on the openwrt page:
Warning The 5 GHz radio / Qualcomm Atheros QCA9886 support seems to be buggy in some cases.
Some users report much improved long-term stability with 5 GHz by using the closed-source ath10k firmware instead of the open-source ath10k-ct firmware. To do this remove the packages “kmod-ath10k-ct” and “ath10k-firmware-qca9888-ct” and instead install “kmod-ath10k” and “ath10k-firmware-qca9888”.
Ok I successfully changed the 2 packages on the 2nd router which is configured as DHCP client (dumb AP). When I do this on my main AP the 5ghz seizes to work. radio0 is not active and Wireless says it is not associated. I tried to remove and add the network again but then I'll get an error "Cannot read properties of undefined (reading 'value')".
Since I didn't know what to do I reset the main AP and setup everything again with the initial packages and now it works. So both routers run on different packages now but I guess that's not ideal?
Did I install the packages wrong? I deleted “kmod-ath10k-ct” and “ath10k-firmware-qca9888-ct” and installed “kmod-ath10k” and “ath10k-firmware-qca9888" in that order. I began with the dumb AP though if this is important.
Oh and @frollic Openwrt version is 21.02.3.
It isn’t that many weeks ago we had the post here about poor performance of eap245.
The real difference between ath10 and ath10-ct is actually that ath10 is the old and obsolete manufacturer drivers and ath10-ct is the same drivers that one person has kept on developing.
So there is no guarantee that changing the drivers will work for a specific hardware at all, sometimes it works and sometime it doesn’t work. The ath10-ct seems to be more evolved to work with “popular” 5GHz chips than “uncommon” 5GHz chip.
incorrect, ath10k is the driver in mainline linux, it's pretty distinct from ath_pci (the closed vendor driver found in most commercial routers).
Most of the difference is in the closed firmware blob, the drivers are mostly interchangeable.
Not quite, the hardware coverage is the same, either should work, how well is another question.
Well this was the conclusion for the performance issue of the eap devices with -ct vs non -ct drivers.