It is in /etc/config/wireless
See example in prior post I was replying to:
1 Like
In LuCI it's under Network -> Wireless -> Edit -> Wireless Security -> Enable key reinstallation (KRACK) countermeasures.
Cheers.
1 Like
Good to see that SOMEONE(s) is still working on this!
My behavior is a bit different, its every few days the 2.4ghz radio goes unresponsive, little to no indication in the logs, but almost always recovers on its own. I get the occasional kernel warning from ath10k, as well, but dont seem to see loss of service on 5ghz
Edit: was mistaken about the KRACK being missing from snapshot, it was the management frame protection stuff. I'll try turning off the KRACK stuff, always have enabled it in recent years.
A thought, now that theres more than a few C7 users here, what version, and maybe more importantly what chip versions, do you have? I have an odd "V3" which dosent match the pics on the hardware site. It uses the external antennas on 2.4 and 5ghz, no internal 2.4 antennas. Anyway. My SOC (main processor and ath9k radio) is a QCA9558 ver 1 rev 0.
I dont know how to get the ath10k radio HW info. It dosent show up in the klog like the SOC info. Anyone know a command to bring that up? Maybe radio versions will be a clue.
Just had an outage while typing, and in the middle of wifes company meeting...though this time it was the WAN eth in my separate router dropping, not my C7 AP! Wholly different problem, but how many times might I have mistakenly thought it was the wifi issue? Well, another issue to chase...
Btw, I'm testing now latest DD-WRT to see if this problem is existing there as well. So far, I'm getting other issues but since 24hours it looks more stable to me then Openwrt.
Let us know what happens. What versions of ath9k and ath10k modules and firmware are they using?
Also, anyone come back wirh their hardware chips, to see if we are a batch of different, or mostly the same? Anyone reading this and NOT having radio problems please check and reply.
1 Like
Too late to check myself, I had to switch back yesterday midnight as some devices have got troubles, eg. Samsung S9+ reporting "Access point is full", another device OnePlus Two getting disconnected each 15min or so etc. The true is that some other devices in the opposite were even more stable and the wifi didn'd die like in case of Openwrt.
But anyone can give a try himself, I switched to and back even directly between dd-wrt to openwrt without stock firmware.
https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2020/06-15-2020-r43420/tplink_archer-c7-v2/
How to :
I have a mix, IIRC v2 and V3 use the same build, primary diff is antennas as you noted. V4 and V5 also see this same issue, so I do not think it's hardware version related. And since I see the exact same thing with MT76 units, I'm now suspecting it's an issue in mac80211 kernel code.
I was able to 'unstick' a 'frozen' (no wifi traffic flowing, could not even ping AP) AP by issuing a random iw command (e.g. iw dev ), but not sure yet if it was timing coincidence, or a byproduct of invoking a command that pokes the mac80211 stack. My AP locks every couple of days, so still waiting for the next occurrence. BTW- I've not rebooted, and all is still fine.
1 Like
And it just happened again, and an 'iw dev' got it right back. Again, not sure if timing coincidence or side-effect of running the iw utility.
How long had it been running before it froze?
I’ve had to use a cron script to reboot the AP every morning so I don’t get freeze ups.
1 Like
Less than a day ~18hrs. But I'm fairly sure a daily reboot would minimize the chances. I'm purposefully NOT rebooting to see if there is a specific mechanism to re-establish connectivity, as that might be a clue as to the root cause.
3 Likes
Just had an outage while typing, and in the middle of wifes company meeting...though this time it was the WAN eth in my separate router dropping, not my C7 AP! Wholly different problem, but how many times might I have mistakenly thought it was the wifi issue? Well, another issue to chase..
Just starting to look thru my old collected logs on this router box eth dropout.... and I'm starting to think I'm mostly seeing those, in recent time. (past 3-4wks) So, maybe a lot of times when the wife or someone yells "the network's down" and I check the 2.4ghz radio but not both of them, take some logs off the AP... maybe it's not the radio!
That would explain the short term drop symptom, and that it "heals itself" if I don't go fix it. If that's the case, I could say that the C7 June 4 snapshot, and it's stock ath10k selections, might have eliminated the radio problem for me. Probably too early to claim that yet. And, it may only apply to my case, where my router and C7 AP are two seperate boxes. But possibly, I've had a fixed setup on the C7, that has had external symptoms looking like the problem continued...
I've updated my separate x86 router box, (almost 138 days uptime, woohoo!!) from 19.07.1, to 19.07.03, maybe that gets me a newer rtl8169 driver for that problem. Will keep a close eye on unexpected eth1 down/ups... as well as watch for further C7 2.4ghz radio issues.
2 Likes
Well, 13 more days of uptime, doesn't seem that I've had a 2.4mhz dropout since, and perhaps for some time earlier than that.
Of course I have a few other settings changes, of which I don't know how much, if any, they affect this thing. I have turned off the KRACK mitigation, that's one thing, and I have the beacon set to 100ms (standard timing) but the DTIM time set to 1 (instead of 2?) So this would send a DTIM packet or whatever, with every beacon. I also run with the 802.11b compatibility off, but that's commonly used by many without fixing this issue.
And, I've been using the C7 June 4th snapshot, and that version's stock ath firmwares and drivers.
FWIW, here they are:
kmod-ath
4.19.123+5.7-rc3-1-2
kmod-ath9k
4.19.123+5.7-rc3-1-2
kmod-ath9k-common
4.19.123+5.7-rc3-1-2
kmod-ath10k-ct
4.19.123+2020-04-29-3637be6f-1
ath10k-firmware-qca988x-ct
2020-04-24-2
Also looks like there's yet a newer ath10k driver, in snapshots, here's from doing a update check today:
kmod-ath10k-ct
4.19.123+2020-04-29-3637be6f-1 » 4.19.123+2020-06-30-edfbf916-1
Oh, and I also haven't seen the mysterious eth port dropout on the x86 router box, since I bumped it up to 19.07.03.
1 Like
Been running a custom build of 19.07.3 (running Archer C7 V2 as an AP) and I'm up to 10 days runtime without a reboot. It seems that 19.07.3 has been a rock solid build for me.
Note that I'm not using stock firmware and drivers for ath10k:
ath10k-firmware-qca988x
2019-10-03-d622d160-1
kmod-ath
4.14.180+4.19.120-1-1
kmod-ath10k
4.14.180+4.19.120-1-1
kmod-ath9k
4.14.180+4.19.120-1-1
kmod-ath9k-common
4.14.180+4.19.120-1-1
Lucky you... ;-(
I take it you haven't had much luck?
Unfortunately not, I'm now on trunk with kernel version 5 and it seems no difference for me - still getting 2.4 GHz dropouts. I will probably soon trow my C7v2 away as there is not interest to get it fixed ;-(
After reading about this issue so long just would like to say that at latest Gargoyle version my Archer C7 v2 is rock solid for both 5gz and 2.4gz band for a looooong time.
Using openwrt at my TL-WA801ND only
Hope one day it will be fixed so i can switch back to openwrt with my Archer C7 v2
Hi,
Just a feeling, but some weeks ago I decided to reduce running SSIDs on the same Archer AP from 8 to 3. Feels like this also contributes to stability, only one dropout under heavy load so far.
Could you post the ath9k/10k drivers and firmware versions that Gargoyle uses?
1 Like
Sorry for delay
The version that i use is 1.12 and here is the link for downloading it
https://www.gargoyle-router.com/downloads/images/ar71xx/gargoyle_1.12.0-ar71xx-generic-archer-c7-v2-squashfs-sysupgrade.bin