Thanks for the tip! I'm giving LEDE a shot. Won't help me much with my A7 v5, but if it works on the C7 v2's, I might take a swag at backporting A7 support to LEDE.
TopDog, I should have responded to you specifically as well...
My channel and power were locked.
How congested? I'm not sure how to quantify that. In terms of other SSIDs on the same channels, not a lot. I live in a residential neighborhood with quarter acre lots where the neighbors' SSIDs don't bleed too far into my own house, and there are few visible SSIDs. As stated, I am using 1,6, and 11 amongst all my APs, and each of them exhibited the same issue.
I disabled ANI, applied the hardware ack (ath9k nohwcrypt=1) change, as well as disabling low ACK disconnects with no appreciable improvement. I also tried using the ath10k ct-htt drivers, though I don't think those apply to the 2.4Ghz radio.
If I could, I'd love to try the ar71xx images on the A7. I suspect this is something unique to the newer ath79 drivers.
1 Like
Anyone has idea on why shutdown the wifi and then enable it will fix wifi dies problem?
I have same issue.
5GHz WLAN on my Archer C7 v2's (18.06.1) works perfectly for months on end, no matter how many devices attached.
But 2.4 GHz WLAN will run couple of days or weeks (depending on volume of data) and then suddenly stop sending packets whgile devices are still associated to it. System or kernel logs do not indicate anything unusual but devices cannot communicate until I restart 2.4 interface. I tested disabling "Disassociate On Low Acknowledgement", no change.
Is this a WLAN driver or OpenWRT issue? Is downgrading to old LEDE version only thing that helps? Can I reuse LEDE WLAN 2.4 drivers instead?
Does shutdown WiFi then enable it solve this problem? It works for me with snapshot build.
I'm having success with the latest LEDE Reboot 17.01.7 as @Rednas_N suggested. I'd not had any success with restarting the interface when I was using snapshots, but I still have an A7 v5 that I could try this on. Been trying to avoid re-adding that AP to my network until I've gained some confidence in the current network state with the two C7 v2's running LEDE. I might plug the A7 back in tomorrow and put it back in the mix with the latest snapshot.
One if the issues I have with running the A7 in the current unstable state is that it's difficult to determine from the AP end if there's any client issues. So the only way I could maintain some sort of stability is to pin those clients who need it for coverage to that specific AP's SSID, ping the clients from the AP and restart the interface and/or AP in case of X lost pings. Not ideal, for sure.
If I could do some sort of debugging on the 2.4G interface and actually see the failures, that might lead to a better workaround, and possible actually help narrow down the conditions of failure. Anybody know if there's a way to make the driver spit out more verbose info in the debug level logs? Debug level alone doesn't seem to give much in terms of clues.
Small update: I'm running a recent snapshot on my A7 with the ath10k firmware from LEDE 17.01.7
opkg remove ath10k-firmware-qca988x
opkg install http://downloads.openwrt.org/releases/17.01.7/packages/mips_24kc/base/ath10k-firmware-qca988x_2017-01-11-ab432c60-1_mips_24kc.ipk
With this combo, the clients on 2.4 seem to be stable. Unfortunately, my 5Ghz radio seems to unable to start. Not sure if I screwed something up with the configuration, or if it's the firmware.
EDIT: Looks like the 5Ghz problem is with DFS. If I select a non-DFS channel (36 or 149) then it works fine after a reboot. Seems like getting the interface to come up when using a DFS channel is either slow to start, or doesn't start at all.
2 Likes
Still having success with this setup?
Yes. Both my C7s and my A7 are rock solid now, with uptimes of 23 days and 12 days respectively. This was unheard of when I was running 18.04 or snapshots.
I see that 19.07 is now in release candidate. Not sure when I'll get around to testing that. I suspect that given the recent snapshots were pretty unstable, that the RC will be as well. At the moment, I finally have some wifi stability in my house, so I'm content staying put with what I have and concentrating on other priorities.
Hi muchtall,
what is the base version you are using?
Uwe
For which model router? The C7 v2 or the A7 v5?
Base software for Archer C7
Uwe
Sounds good! I installed the 19.07 RC1 a few days ago. Within 24 hours I had issues with my Wifi. My devices told me the password was incorrect. After restarting the WiFi everything was working as expected. Now running stable for at least 24 hours. I have also enabled verbose logging for the wireless device for more information.
If the wireless dies again within a week I will write a script to restart the wireless every day or I will try the solution provided by you:
opkg remove ath10k-firmware-qca988x
opkg install http://downloads.openwrt.org/releases/17.01.7/packages/mips_24kc/base/ath10k-firmware-qca988x_2017-01-11-ab432c60-1_mips_24kc.ipk
As stated here: Archer C7 2.4 GHz wireless dies in 24~48 hours ...
I am running LEDE Reboot 17.01.7 on the C7 v2 APs per @Rednas_N 's suggestion and that's working great for me.
Hi,
Has this ever been fixed?
I have upgraded from 18.06.4 to 19.07, same issue.
Then I upgraded from 19.07 to 19.07.01, same thing.
Then I replaced ath10k-firmware-qca988x-ct with ath10k-firmware-qca988x and kmod-ath10k-ct with kmod-ath10k, same thing.
Is there any way of using 2.4GHz on Archer C7 v2 while retaining 5GHz?
EDIT:
I will have another shot by backdating to old firmware http://downloads.openwrt.org/releases/17.01.7/packages/mips_24kc/base/ath10k-firmware-qca988x_2017-01-11-ab432c60-1_mips_24kc.ipk and report.
1 Like
One question: according to info in another thread, 2.4GHz radio is using ath9k drivers and 5GHz radio is using ath10k drivers. In that case, changing ath10k should have zero effect on 2.4GHz radio stability?
incorrect target
would you mind expanding that? Do you agree that replacing ath10k-firmware-qca988x with http://downloads.openwrt.org/releases/17.01.7/packages/mips_24kc/base/ath10k-firmware-qca988x_2017-01-11-ab432c60-1_mips_24kc.ipk should not be able to fix 2.4GHz connectivity?
no i don't. i don't have firmware sources to see what has been changed in between the two versions and even if i had it would still need some debugging...
wrong bits coming from PCI device's driver or firmware to the main SOC (WMAC integrated-2.4GHz) can cause entire system instability or crash (that's why 2.4wifi is not an exception here) and i've seen this personally while working with QCA9880 v1 (don't think QCA9880 v2 is much different)
OK. Yes, it is plausible that buggy 5GHz firmware might affect 2.4GHz radio...
I have found evidence in some other threads that ath10k indeed affects 2.4 even if it should not to:
I am now testing "backdated" ath10k driver so we will see how it goes. If nothing happens within 2 days then it works! And if it is stupid but works then it is not stupid! 
3 Likes