It has now been online for 4 days and subjected to load that usually brings it down within 24 hours. It definitely works, despite it should not. Both 5GHz and 2.4GHz rock solid. Perhaps someone can do some more intricate debbuging on why 5G firmware bugs 2.4G radio?
This is my "magic mix" for fully functioning Archer C7 v2 with 19.071 image:
2.4GHz stopped responding today. Failure mode was slightly different: some of associated stations were still associated but could not send anything. I tried connecting a phone to 2.4GHz, it would associate but not surf. Two hours later it could connect and surf.
Anyway, 2.4GHz is still dodgy on Archer C7 v2 and replacing ath10k stuff seems not to fix the issue!
The issues manifest themselves when you have multiple connections. I have 6 clients, 1Gb fiber connection and after few days, it will bring 2.4GHz down. If you use low bandwidth single client and have ADSL you will unlikely experience same kind of issues.
@Gruntruck My experience has been the same. Two low traffic IoT clients chug along for a long time. Introduce one streaming and/or gaming machine and it goes south fast. BTW This happens only on wireless. Ethernet switch works just fine on any load.
I have the same problem with 2.4GHz on Archer C7 v2.
After upgrading my uplink from 100 Mbit/s to 1 GB/s the 2.4 Wifi dies a lot more frequently...
5GHz is still running fine.
When the error occurs, the following message is logged in syslog:
Sun Mar 29 14:13:06 2020 kern.err kernel: [ 4218.030163] ath: phy1: Unable to reset channel, reset status -5
Sun Mar 29 14:17:27 2020 kern.err kernel: [ 4478.945333] ath: phy1: Unable to reset channel, reset status -5
I was able to reactivate 2.4GHz when executing "wifi" command from SSH console.
Another way is to disable and then reenable 2.4GHz wifi with Luci webinterface.
At the moment I use OpenWrt 19.07.2 r10947-65030d81f3 with:
It is not OpenWRT per se that is failing, it is ath9k 2.4GHz firmware blob that is buggy. I now only use 5GHz on all my C7 dumb-AP's and it is rock solid. It seems that whatever 2.4GHz blob that is "baked" into distro is buggy. Perhaps we should try with some very old one?
2.4GHz usually kinda works, as long as you do not "load" it with many devices and/or high throughput. This was the issue with Archer C2's as well, so I got rid of those.
Old firmware didn't work for me, nor htt version of ath10k-firmware-qca988x-ct-htt, now I'm testing smallbuffers - kmod-ath10k-ct-smallbuffers. Btw I'm on latest trunk. Also turning off "Disassociate On Low Acknowledgement" didn't work for me.
I was never able to make 2.4G work well on OpenWRT C7 distro regardless of version. On the other hand, 5GHz always worked flawlessly. (Same with Archer C2). As far as I understand, ath9k firmware blob bundled with OpenWRT is somewhat "closed source" so only thing you can do is roll with factory blob and hope for the best. Unfortunately, something is not playing nice with OpenWRT.
Also, this was never actualized enough as 2.4G "mostly" works. Bug is unlikely to be triggered by someone with two devices sitting on ADSL. But if you have >100Mbit WAN and many devices, chances are you will trigger it. I just use C7's as 5GHz AP's/edge switches and that's where they excel.