Just fyi: I didn't enable soft flow offloading. Against some dropouts on 2.4 G I've found a workaround specific to 802.1x eap-tls (radius driven corporate) wifi that works to keep our mobile phones solidly connected.
option eap_reauth_period '0'
(from my mind of another thread here : Driver cannot safely Rekeying with 801.1x - #11 by Catfriend1 )
Whole thing crashes, or just the 2.4ghz radio goes down, like the thread topic? Any info in the logs? We need to get some documented info here, for the developers, folks...
I also have never tried the sw flow offload. In a recent test, trying to get some info, I disabled my cron task to reset the wlan1 at 4am. It took a couple weeks before I got the first problem again, then 2days, then again after 3hrs... So, quite a variability.
This with the household load of 22 items and systems connected, varying Zoom call, netflix, youtube, a gamer playing various multiplayer games... that kind of load. As I've stated, I've also tried hammering many 16 up/down flow speed tests and such, without ever provoking an issue, so it seems like some kind of traffic or combination of traffic is the trigger for me. Also remember, I'm using the C7 just as an AP, have an x86 box doing the routing.
If I get motivated, I might try buying some better caps that would be right values and fit the pads, and replace the PS caps. Or, poke around with a 'scope and see if I see any drops on the supply lines, that might warrant changing caps. A bit of time and effort, after I take down the family AP and replace it with something while I test.
Any of you folks have any visible events in the logs when this happens for you?
Also, can you all check with top when you have an event, and see if your C7's have a high system usage like I mentioned seeing, up thread? (high sirq %,low idle time %?)
Hello
I have a similar problem with the same chipset (based on athk9) that I could only solve, turning off encryption ... It is now fully stable, even if it is not secure at all (limited to mac address).
I describe it here, maybe some of you can make a try. Here I posted my issue.
Maybe it can give you (the experts) some hints how to proceed.
Thank you!! 
Apologies for necroing this thread. However, something interesting got posted into OpenWRT's master branch regarding the chipset used for anyone still using this device. Note the patch notes used a "Yuncore XD3200" for testing. It uses the same CPU as later Archers, such as the C7/A7 (v5) - a QCA 9563 SoC with the 9561 as the ar9003 radio. Integrating this patch will also boost power output and thus, throughput. This may also fix the large number of collisions on 2.4GHz, but I have not tested this yet.
I recently "upgraded" my Archer C7 v2 from 15.05.1 (where it was rock solid stable and ran for months without reboot), to 22.02.1 (via 19.x) and the process was pretty much without incident.
However, after about 4 days, I got the issue where 2.4Ghz started to drop its clients. I tried all the tricks mentioned in various threads - daily reboots, ath10k firmware variants, tweaks to the radio settings, but nothing worked. I found that the dropouts happened when my son was streaming video. His PC is at the other side of the house and the 2.4GHz signal is poor (about -76dBm). There was nothing in the system or kernel logs to indicate an issue. Just 2.4GHz clients were dropped and unable to reconnect. No disturbance to 5GHz clients or wired ethernet. I briefly considered trying to go back to 15.05.1, but I thought that the security risks probably outweighed the stability factor.
In the end I re-purposed an old wireless gateway as a 2.4GHz Access Point and disabled its WAN and DHCP settings. I was able to locate it in a more optimal location and connected it via ethernet to the Archer. I then disabled 2.4GHz on the Archer and just run 5GHz and hard-wired connections. It's been stable ever since and my son now has excellent 2.4GHz reception and throughput.
I would echo what many other contributors have said about the 2.4GHz performance on the Archer C7 V2 - it was solid on older versions of WRT but something changed during the LEDE variants which affected stability and this seems to continue right to the present.
My C7 V2 is pretty solid, and has been from LEDE 17.01 to OpenWrt 21.02
It may just be something in my environment or use case. When I upgraded to LEDE from 15.05.1 several years ago, I had similar instability on 2.4GHz, so I reverted back at the time. Definitely a software/driver issue triggered by load or some event on 2.4 causing a lockup. In any case, setting up a separate AP for 2.4 has allowed me to disable that particular radio on the C7.
At the moment I have FTTC (Fibre To The Cabinet) which gives me about 66Mb/s on the copper loop from cabinet to the house. Recently, fibre has been installed in the ducting in the street, which will potentially provide a 1Gb/s service offering. At that point I will have to reconsider my whole router setup!
Thanks for your assistance in the sysupgrade process, though. At least the main internet-facing router is up to date and I've learned a few things along the way.
Yep, agreed on use case may be influential on this one. I've been battling the problem for years... with a home situation with one user in a far bedroom, poor signal, doing a lot of gaming, vid/audio chat, etc. He started classes a while back, and after complaining a lot, a ethernet cable took his traffic off the air. Before that his data habits changed somewhat over that time as well. This also coincided with 20 to 21.xx version updates, trying some master versions, etc, so it's hard to tell if improvements were more due to updates vs traffic changes. Things are currently a lot better, with occasional issues on 2.4 and rare ones on 5.6ghz. No more resetting the wifi radio's every night and still having the problem come up.
You're not the first to report having a "far" station with weak signal in the mix, of people reporting this. Type of traffic could be part of the picture as well.
Thanks for that feedback. I've seen a lot of your posts on this issue in various threads. The 2.4 drops are a particular pain for me as the house alarm uses wifi and GSM for alerting/monitoring purposes and if wifi drops the key panel starts beeping and I get an alert on my 'phone. If this happens at 2am it's kind of annoying! No 5Ghz option for the alarm, unfortunately. In any case, setting up a separate 2.4 AP has resolved the issue
Several months ago, @sammo found a workaround: disable 'ldpc'.
since I put the following in config/wireless:
config wifi-device 'radio1'
option ldpc '0'
I never encountered the dying 2.4 Ghz issue.
Hmmm, I believe I tried that with no benefit. Either that or my C7 did not have the option.
Reading back in this thread, I see I did not find that as an option to set, and I think I wasn't able to apply it and have it stick.
Also, it seemed Sammo didn't have a C7, and his chip was not the same one, just "in the family". And, uh, you were saying that you tried it, and it didn't work for you. Did something change along the way?
802.11n -
802.11ac -
It's an available option on the C7 V2.
I have 3 wdr7500s with flash size modified to 16MB, I run C7V2 firmware.
Before disabling 'ldpc' option, I had been having dying 2.4GHz issue, no matter with -ct or non-ct 5Ghz driver.
But since I disabled the 'ldpc' option in 2.4Ghz, no more dying issue, no more need to scan in cron.
So my case is for C7V2.
oh, it did not work at first try because I forgot to remove the 'txq limit' workaround, after removal, it worked.
Ok - good to know that you are running C7 V2 firmware and having success with that setting. I did see @sammo's posts in another thread regarding 'ldpc', but I thought the hardware/firmware was slightly different, so I didn't actually try that particular tweak. At the moment, I actually have way better 2.4GHz coverage in the house using a separate AP located in another room which is connected back to the Archer by ethernet.
Well... I might disagree with you that you have a "C7V2" case there, if your hardware is different, even if it runs with the C7V2 firmware.
Looking back in this thread, when this came up, I found that ldpc was not in my config, and IIRC, I couldn't make it take it. I have a real C7 v2.
I'd like to see if any other C7 v2 folks (or other "real" C7 versions) actually have that in their configs, or are able to add the command.
Run iw list and check the Capabilities sections.
RX LDPC is supported on my C7 V2, but I don't use it.
wdr7500 (v3/v4/v5) is a 'downgraded' version of C7C2, sold mainly in China, it differs from C7V2 only in terms of flash size (8MB).
once upgraded to 16MB flash, I believe wdr7500 is a 'real' C7.
Can you edit the file /etc/config/wireless ?
Just noticed this happening with 2.4 ghz. I'm surprised nobody has found a workaround yet. I only noticed because somebody connected with 2.4 for range.
Is it C7v2?
Thank you very much @sammo ;
after several months struggling with this issue on a TPLINK CPE 210, this single line in the network configuration made it, finally, STABLE.
/etc/config/wireless:
config wifi-device 'radio0'
...
option ldpc '0'
