It is not OpenWRT per se that is failing, it is ath9k 2.4GHz firmware blob that is buggy. I now only use 5GHz on all my C7 dumb-AP's and it is rock solid. It seems that whatever 2.4GHz blob that is "baked" into distro is buggy. Perhaps we should try with some very old one?
2.4GHz usually kinda works, as long as you do not "load" it with many devices and/or high throughput. This was the issue with Archer C2's as well, so I got rid of those.
Old firmware didn't work for me, nor htt version of ath10k-firmware-qca988x-ct-htt, now I'm testing smallbuffers - kmod-ath10k-ct-smallbuffers. Btw I'm on latest trunk. Also turning off "Disassociate On Low Acknowledgement" didn't work for me.
I was never able to make 2.4G work well on OpenWRT C7 distro regardless of version. On the other hand, 5GHz always worked flawlessly. (Same with Archer C2). As far as I understand, ath9k firmware blob bundled with OpenWRT is somewhat "closed source" so only thing you can do is roll with factory blob and hope for the best. Unfortunately, something is not playing nice with OpenWRT.
Also, this was never actualized enough as 2.4G "mostly" works. Bug is unlikely to be triggered by someone with two devices sitting on ADSL. But if you have >100Mbit WAN and many devices, chances are you will trigger it. I just use C7's as 5GHz AP's/edge switches and that's where they excel.
I made some modifications to your script and made it into a function suitable to be placed in System > Startup > Local Startup, ie:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
### Keep an eye on the 2.4GHz ath9k interface and restart it if no clients are connected
wifi24watchdog() {
while true ; do
sleep 60
grep -q 0 /sys/kernel/debug/ieee80211/phy1/netdev:wlan1/num_mcast_sta
if [ "$?" -eq "0" ]; then
/sbin/wifi
logger wifi24watchdog restarted the 2.4 GHz radio
fi
done
}
wifi24watchdog &
exit 0
This also invokes logger so you can keep track of how often this is firing in the System Log.
Switching to 20 MHz doesn't work for me. I also tried all combinations of firmware and kernel modules for 5 GHz. I have latest stable LuCI 19.07.
I'm also posting testing procedure, so anyone can reproduce this problem. You can use iperf on 2,4 GHz SSID and it will fail in hours.
open ssh to router
opkg update
opkg install iperf3
iperf3 -s
download iperf client on PC - https://iperf.fr/iperf-download.php
connect to 2,4 GHz SSID
iperf3.exe -c 192.168.1.1 -t 86400 (change IP to your router IP)
the connection will fail after 1-3 hours
Used to experience something similar... Not sure what I've done or not done, or what the neighbourhood has been doing, but the below config on 19.07.2 has seen me through a month of run time without any problem:
Were you still running this script during test? Please disable it during the test. It is a solution, but not for me, because I have 0 clients many times in normal operation.
Then I tried to move the notebook closer to the router and it worked fine. I suspect the bug has to do something with high bandwidth and large number of retransmission due to lower signal quality. I don't have any experience with debugging this kind of problem, but I can test it if anyone finds a solution.
Ipref3 on 2,4 GHz with 20 MHz channel gives me:
near router with around 40 mbit/s: didn't fail in 5 hours
next room with around 15-20 mbit/s: fails in 1 hour