Can you share your build ?
1 Like
Hello folks. Figured I could comment with my own experience.
I've been watching this thread for a bit and i've had major problems with 19.x when I first migrated to it. I could barely get a few hours if not minutes with the devices becoming unresponsive. It did not appear to be a memory issue based on logs. No variation of ath10k packages changed the behavior. No special changes around KRACK, inactivity timeouts, flow offloading etc. Pretty default aside from zones, AP/client, routing.
With ath10k-firmware-qca988x-ct-htt and kmod-ath10k-ct-smallbuffers on a fresh reset as well as everything re-configured by hand, its been working pretty stable. At least no worse than 17.x was. All the other packages are updated to their latest version.
Activity & traffic is quite high as I use it in a business setup w/ a fibre uplink.
I have two v2 devices acting as an AP, and another as a STA using WDS.
Both devices serve 2.4 and 5ghz with the STA using both radios to connect to the AP.
In addition I have a virtual interface to serve guest wifi on 2.4
There is a lot of heavy traffic with a NAS and a Pi manging VPN via strongswan connected to the client.
I have not been able to identify what in the configuration is different from the initial installation of 19 upgraded to 19.07.3 to my fresh install on 19.07.3. So far so good?
1 Like
Hello marok,
have you changed the 5GHz channel?
With channel 44 my C7 seems to be very stabile.
Uwe
Hi marok, thanks for adding your experience.
I'm trying to follow what exactly you did. Is this right: You were on a previous version of OpenWRT, then you upgraded to 19.07.3 and had a lot of problems, then you did a fresh install of 19.07.3 and reconfigured all your settings and it has been stable?
So when you did your initial upgrade to 19.07.3, did you take the option to preserve settings? I have been having 2.4 GHz cut out within a few days, and I always upgrade by not preserving settings.
Thanks!
@uweklatt. I run mine on 36: 80mhz, due to being near an airport and DFS. 52 still worked fine just not ideal. Canadian band regulations
@smeep Correct. Though I tried a few things:
- One device I tried 18->19 keeping settings. Not stable
- Another device 19 (one of the earlier releases) direct. Not stable.
- Tried 19.07.3 fresh followed by backup from 18.x. Not stable. Then updating to trunk
- Variations of the ath10k drivers
- Keeping devices unlinked from each other. No difference.
For all I found the 5ghz radio would even fail to start unless i did a restart on the radio from luci after it booted.
So this time around. Fresh install of 19.07.3 first thing i did is change the ath10k packages. Update the rest of the packages. Then configure. So far so good for a week? Perhaps it was the order of operations before I configured it.
opkg update
opkg remove ath10k-firmware-qca988x-ct kmod-ath10k-ct; opkg install kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct-htt
opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade
Differences I spot in the two configuration backups are minor. LED settings in system, default firewall rules have more icmp types. One of my additional zones is created with a default bridge associated with to it. The port syntax for the vlans in network are slightly different.
For what its worth, I found out that 80MHz on 5GHz is buggy and if you don't need 866Mbps+ speed then switch to 40MHz and setting channel to 44 is working great for me. I also have 0 problems on 2GHz channel set to 1 at 20MHz. Both radio power levels are maxed out.
I'm on snapshot build with default kmod and QCA packages (-ct pre-installed) on Archer C7 v5.
1 Like
It's a good point, I don't need to use the 5 GHz because my connection is a 50 mbit VDSL. With that connection speed, all you need is a 20 MHz channel. I have used 20 MHz on 5 GHz before when I noticed that a PC that I had temporarily in a new location wasn't doing as well on 2.4 GHz for some reason--normally it is on a LAN cable.
I'm preferring to use 5Ghz because syncing from pc to phone goes with naerly 30 mbyte/sec and my nas transfers around 20 mbyte/sec. over wifi. It does not fit for my Google home and alexa devices, they only respond reliably and play multi speaker correctly when on 2.4 ghz.
Why are people still believeing that fiddling with ath10 5GHz drivers will magically fix their ath9 2.4GHz issues? Two separate pieces of hardware. This is some sort of forum truth that has been going around.
You can easily test it, just remove all ath10k drivers (not disable it, remove it all together) and just use ath9...hck, you can even build a "dumb AP" configuration and remove ath10 and it is still bad. It works until it does not. Good way to truly test 2.4GHz is to have wired iperf3 server (a PC) and then have two mobile devices connected to 2.4 running iperf3 clients at the same time. If it does not fold then it is truly fixed.
2 Likes
It's a good point. I believe the argument was that one of the drivers was sucking up memory to the point that it affected the other driver.
Anecdotally, I had a work video conference freeze on me today, and GoToMeeting said that my bandwidth was too low to support video. I ran a speed test and it showed very slow upload speed. This is over the 5 GHz radio. I restarted the 2.4 GHz radio, and then my 5 GHz speed went back to normal. I can't really explain it.
2 Likes
But it is not really the case. 2.4GHz will fold at high load despite router having plenty of RAM left. It will fold even with 5GHz drivers not loaded at all.
Update on my side. One of my routers is now damaged. Began with both radios failing to work. Then even failsafe doesn't start. Booted a few times over a 100 power cycles or so but it's likely toast. I did try to reflash during one of those working cycles but no luck.
No date on the device itself, but sometime late 2014. 2.0 revisions. They had a fantastic run and were quite stable. Up until I put 19.07 on it. Quite stable in AP, less so in STA mode (which is the one that died).
1 Like
Hi
using the wdr3600 gives same problems, both on ar71xx and ath79 at least on 19.0 version.
Posting this since, the wdr3600 seems being used by far less persons.
Could this be then a mysterious bug on the firmware?
Does anybody know if this bug is reported on bugs.openwrt.org?
Is it possible to manually replace the Ath10k drivers with ones from OpenWrt 18.x? I'm assuming no, but not sure how to determine this. Would mesh be supported?
Could be a failing power supply?
This was an issue for me at one point for a cable modem.