Perosnally, I prefer putting the mesh on 5 Ghz because I've got more bandwidth on the backhaul. e.g. my mesh "repeater" bridges the internet from "mesh-wifi (input) to lan (output)" (input/output not technically) and I use it on my tv "area" in the living room so the mesh "pumps" data for the lan clients tv, playstation, chromecast and a guest notebook. (my "base" router is connected to the internet and throws about 500mbit/sec over the mesh "bridge"). With 2.4 ghz it would be slower under my wifi interference environment with neighbors.
Basically your setup looks fine as you'd described it. I am for example running a lot of bash scripts on one archer and that was a while ago the "most instabelest" until I discovered that heavy "spike" loads could "crash" wifi drivers. e.g. performing heavy usb mass storage writes and find / searches simultaneously. If in doubt, please test the router in dumb access point mode, so without wan/nat, routing, firewall, etc. "just bridge lan to wifi" and see if it gets better.
On OpenWrt 19.07.X, have you tried removing kmod-ath10k-ct and installing kmod-ath10k-ct-smallbuffers? I have an Archer C58 v1 router which constantly crashed every 8-12 h with a high 5GHz network load - several devices using VPN services with MS Teams etc. - as there were 3 people in the house working from home. I removed the default kmod-ath10k-ct, as the Archer C58 v1 has 64Mb of RAM, and when I replaced with kmod-ath10k-ct-smallbuffers I have had no issues for several days. I carried out the following steps.
Not too much talk about Ethernet above, which makes me think I actually have the same problem but have been thinking about it wrong.
Is anyone seeing Ethernet go out too, or is that a parallel problem? If anything, it's gotten worse with the recent 19.07 point releases here, and since I can't access the router at all once it happens until it's cold-booted, it's a little difficult to figure out.
It's definitely a router under heavy use, but that's always been true.
Ethernet has always worked for me flawlessly. Thought the same for 2.4GHz WiFi for 5 years until recently. I used to run C7 v2 as dumb AP with two SSIDs backhauled to another router via VLAN trunk. However, I have recently started using C7 as a Wireguard server for my remote IP camera recording. Although Wireguard runs only through wired, 2.4 GHz wifi began freezing every other day or so. It just seems that high CPU usage kills it.
I will try replacing the power supply to rule that one out, at least...
I'm running an GL Inet AR300M with OpenWrt 21.02rc1 which uses ath9k driver.
I'm also experiencing the same symptom where the wifi dies or slow to a crawl with heavy traffic.
I ran iperf over wifi which causes it to crash within 1-3hrs. I have tried to diagnose the problem and have found a workaround where it stops the 2.4GHz wifi crashing without a wifi down/wifi commands.
For some reason, doing a quick scan stops the wifi dying and/or also recovers it should it dies. Your clients will stay connected.
You will need to add to /etc/rc.local,
while sleep 300; do iw dev $(iwinfo|grep -m 1 -B 2 'Master.*2\.4'|grep ESSID|awk '{print $1}') scan trigger freq 2447 flush >/dev/null 2>&1; done &
I have also monitored the wifi event without the workaround
iw event -f -t
and notice when things goes bad you get event number 64,84
64 = notify_cqm
84 = probe_client
Just a follow up notice: I saw your command to trigger the scan depends on iwinfo, which is by default not available and requires "opkg update; opkg install iwinfo".
I've found a command to do the same without requiring iwinfo.
I notice it slowly dying until I tuned the period to 30 secs, not ideal. It would be great if we could detect the slowness and then trigger the command
@sammo: Just to understand your findings better, I've got those event 84 on wlan0 (5 GHz radio) but they occur rarely. Does that mean my AP got - according to your findings - instable already or does that have nothing to say because it's not the 2.4 GHz radio which sent the event?
I'm not sure as I dont have 5Ghz on my device. iw event should tell you what events are happening on wifi.
i have the scan command run every 30 sec and I haven't experience any drop out. It's not a fix but a workaround
Also planning to update this watchdog to act iw event code based just-in-time with the iw scan if this thread and input by @sammo turns out to be a better solution to work around wifi problems on the Archers.
