I've now waited a long time to observe why my Archer C7 v2 and v5 units got bad performance on 2.4 GHz and sometimes complete crash of the WiFi drivers while the LAN interfaces are still working.
It all seems to boil down to OpenWrt's decision to include ath10k-ct drivers instead of ath10k (non-ct) drivers since 19.07.x releases.
Since then, many users including me according to the below referenced topics have the same issues, e.g.:
2.4 GHz download speed is capped around 10 MBit/sec.
ath10k driver crashes, requiring "rmmod ath10k-pci; sleep 10; insmod ath10k-pci;" or "reboot" to make the router work again.
5 GHz max bandwidth is a lot slower than with non-ct drivers, but still okay
the feeling "of less WiFi range", because devices that are further away seem to have trouble connecting at 1st try. For me, standing at the exact same distance, I've observed my devices connecting fine.
It's a "mysterious" story since then, because I've read a lot of threads here (and participated myself), I feel like 80% of the feedback I got for my "ath10 non-ct builds" was "hey, my WiFi problems with the Archver C7's were solved thank you." and the rest like "not sure - or it's the same like with ct drivers".
This leads me to kindly ask you to consider including ath10k (non-ct) drivers in the next upcoming major OpenWrt releases. It would save me and other people the effort to build a new OpenWrt image ourselves whenever a new official stable commit is available as release. I'd hope to use the official built images again in the future and also advise other people to use them. You are really doing great work on OpenWrt!
well, for sure this is not something strictly linked with the C7, but to be honest it is a mistery also for me the decision to switch to CT drivers..
in my case (i have a R7800) now and then i try again the CT version, but finally i end up always installing back the non-ct because something doesn't work.
Some month ago, i could not get my IOT devices based on espressif chip to work.
Now they seem to work, but my xiaomi phone (bought in 2020!) has ping in the order of SECONDS, i can't even use whatsapp web.
i assume there is something both of us are missing for the usage of CT drivers, i just hope i'll be able to build with non-ct version also in the future..
PS: on the other side, CT drivers are way faster with 160MHz channel width..
For a long time until i find the Catfriend1 Firmware, which i am using these days and my 2.4 GHz and 5 GHz is rock solid stable, i had maximum of 48h stable operation and after i need restart my router.
I had a lot of issues with version 18 and 19 at my Archer C7 V2 EU and this was the reason that lead me to go for Gargoyle (which is base on OpenWRT).
So i can confirm that Gargoyle Firmware and Catfriend1 is stable without crashing.
For Gargoyle i can confirm of 2 years stable operation, for Catfriend1 a week and still continue.
Home Setup
At 5 GHz: NUC10, Smart TV, Game Console and Smartphone
At 2.4 Ghz: a lot of IoT devices (about 20)
For me default -ct drivers are just working fine and stable for months now. No speed caps or connection issues. I tried non-ct as well back in first I was diagnosing problems (stated below) and they also work OK.
I had problems like client-steering, client-disconnections on both bands and I solved them by utilizing custom scripts and Wi-Fi config, hostapd.sh settings. I just never had speed issues though.
The speed issues could be reproduced with Intel 8260 based wifi adapters on 2.4ghz. Plus, non-ct drivers support IBSS and wpa3-sae encrypted 802.11s mesh which I could not get running with ct drivers.
Exact same reason, why I also use the non-ct drivers on the deployed archer units. Missing support (iwlwifi), or unstable operation (mt7xxx) for encrypted 802.11s mesh and RSN-IBSS on 5Ghz is my greatest annoyance in the Wifi landscape
I use the CT-drivers on my r7800 with mesh/batman-adv. The trick on the R7800, at least on this particular router, is to disable powermanagement on the cpu. Very stable. Without this it’s a crashing mess.
Despite some issues with specific versions of their drivers, and missing features....there is also a vast amount of bugs fixed that are still in the original non-CT variant, so there is a lot of variables here that can result in bad performance.
It seems to me that this is device / chip specific issues, so I think a good solution would be to only use non-ct drivers for some devices and only on the stable release branch...
or maybe consider two sets of image for some boards...
I screwed up my device last night by updating some packages, good thing I had backup though. Installed latest snapshot and this time I decided to use non-ct driver/fw.
I must say it feels like same before, rock solid good. Maybe ct/non-ct is more like feature-wise problematic for some users.
On my device I installed the non-ct drivers. When my kids started their online meetings, the ap got reset/restarted, no crash in the log. Just activated WPA2 with Dawn and fast roaming. This happened twice within 2 min. I did one more test, starting a download and it reseted again. So I got rid of the non-ct drivers and since I have the ct drivers, all is good.
Also consider that there is many improvements to CT variant drivers in master since last release, and that the next release will probably resolve these issues even with CT drivers
(next release means 21.xx.xx since it is 2021 already)
If anyone here is comfortable with TFTP recovery, feel free to try a snapshot build
(not likely that you would need to recover, but you never know)
I've been running snapshot images for a while now on Netgear R7800, UniFi AP AC Lite and Archer C7 v4. In my environment I have stability issues with a Nest E thermostat and 2018/2019 MacBook Pro laptops with CT firmware. If I switch the firmware to mainline, the issues are gone. Throughput is also terrible with CT. The driver doesn't make a difference, CT or mainline they both work, it's all about the firmware.
I reported many of these issues long time ago and there are no fixes. Here are my latest perf numbers from yesterday, I do try CT once in a while hoping for magic fixes but so far they haven't appeared. https://github.com/greearb/ath10k-ct/issues/138#issuecomment-778880989
I started a thread too before I found this one. I struggle to understand the decision to default to CT when there are many threads with similar issues reported.
the reason of the ct switch is that while on mainline firmware we never know the changes... ct produce a changelog of the changes and actually the reported bugs can be fixed since ct have source code and can produce their firmware.
So if many people report the problem in a good way (not the chip works good on the oem and works bad on openwrt) the problem can actually be fixed and a beta firmware can be produced asap. It's the interest of ct company since it does sell that chip and these problem are also present on their chips.