Hi,
Thanks so much for sharing your builds Catfriend. I installed your 21.02.0 stable build on my V5 yesterday and I'm going to give it a few weeks to assess stability. So far things seem really snappy and the wifi reach is great.
A note that I am installing this build because the stock 21.02.0 gave me video stuttering and drop outs on Google Meet calls both with wifi and hardwired.
I will let you know how it goes in a few weeks.
I just want to mention that my experience is the same. Random dropouts on OpenWrt 21.02.0. So far this build has been OK, will update again if dropouts continue. I'm scheduling a daily reboot, just to be safe.
This worked for me; I am running 6 Archer V2s and one Archer V4. The WiFi stability is great with the ath10k non-ct-drivers; I was having lots of drop outs with the ct-drivers and had resorted to using your scripts. Since switching to the non-ct-drivers, the scripts never run and I've stopped installing them.
Also, thanks for posting your imagebuild.sh script on GitHub. It got me started building my own images which makes upgrading a breeze with the non-ct-drivers.
Many thanks for sharing, just to add some additional bits to disabling ipv6 according to:
opkg remove ip6tables
opkg remove kmod-ip6tables
opkg remove kmod-nf-ipt6
opkg remove kmod-nf-reject6
opkg remove odhcp6c
opkg remove odhcpd-ipv6only
Poster confirms this has provided additional stability.
With Metta
To be honest, while removing ipv6 stuffs might increase the stability, 2.4GHz dies eventually.
I am testing the workaround of @sammo that remove 'ldpc'. 7 days running, hope it is the definite/real cause.
My assumption is that the issue is not related to ipv6 nor ath10k driver (ct or non-ct), but ath9k driver itself which enters in a waiting loop when a client station is far from the AP or the signal is weak and don't acknowledge some handshake. And a scan brings the driver out off that waiting loop.
The removal of ldpc in ath9k might help as error checking is different.
note: I own also a wdr7500 v3 modified 16MB flash fake C7V2.
Keep us posted... I haven't tried the ldpc disable yet, may try it later.
I'm working with someone who was involved with some of this code, and am trying to dig up some data for him. I have disabled my nightly cron of ifconfig wlan1 down and up... so that I can try troubleshooting the problem.
Annoyingly, it took nearly 2 weeks till I had an episode again! Then I had them on a much shorter basis. My point being, you might have to wait a few weeks till you have a "statistically correct" conclusion on something actually having an effect. Hang in there and let us know.
It does feel like there's a special interaction of traffic types, or special condition, that needs to occur to cause this. And, it's always difficult troubleshooting, when it's an intermittent, seemingly random problem.
Hi Jon, glad to hear someone is dealing with the code itself.
our concern is likely a race deadlock (atomic action?) in a multi-threaded condition.
In a multi-threaded real-time program, even a simple printk may change behavior.
why a simple iw dev wlan1 scan bring the driver out off deadlock? I think this should be the direction of your investigation.
Just checking in to let you know that Catfriend's 21.02.0 has been rock solid for the past 3 weeks. I'm on an Archer C7 V5. WIFI is working excellent and no problems with running SQM.
Note that I had to move to Catfriend's firmware after installing the regular 21.02.0. After a day with the regular firmware I would get drop outs and stuttering on Zoom calls and Google Meet. Both WAN and WIFI were affected.
I'm following this thread to jump to OpenWRT with my Archer C7 v2.
Is it stable with both band 2.4ghz and 5ghz ?
On c7v2 : 5ghz yes, 2.4 ghz should be ok most of the time but a weekly reboot won't hurt.
On c7v5: yes -yes
Hi! Just registered to the forum just to ask if your build is not affected by the known issue of v21.02? Thanks in advance
Known issues
Some IPv6 packets are dropped when software flow offloading is used: FS#3373
As a workaround, do not activate software flow offloading, it is deactivate by default.
Maybe, it's built from official 21.02.0 packages.
Thank you Catfriend1 for your dedication
Sorry, I'm new to this, but is the ImageBuilder script supposed to be run on the Archer? According to the docs ImageBuilder has to run on amd64. Can't find the architecture of the Archer, but I was assuming it wasn't amd64.
Also, I see that the ath9k-watchdog scripts installs itself into the startup folder, but how is the ath10k-ct-watchdog script set to run on startup?
imagebuilder is only provided for linux (glibc)/ amd64, so just about any general purpose linux distribution (debian, fedora, arch. gentoo, OpenSuSE, mandriva, you_name_it) running on x86_64; it does not run on OpenWrt or your archer c7.
That's what I thought. I wasn't sure though because the script was saving and building things into /root and that seemed odd.
Hi,
you can change paths in the script to your desire. My debian build vm uses /root/... for the imagebuilder but it can also be /home/user/...
I didn't have the ath10k-watchdog trigger with non ct drivers so I left this "unneeded" workaround out.
Just updated the first post with 21.02.1 stable.
Ok, thanks for the clarification.
Thanks for the update to 21.02.1 stable.
After the update my 5ghz is showing 30 dBm maximum power under the Canada country code. I've never seen it this high, is that a bug?