Interesting, I'd like that to be the case so I've decided to try that. Updated driver with updated firmware that leads to a stable situation
I've flashed stable owrt2102-r15934 today, as an "upgrade" from stable owrt1907-r11285. That latter one was my first encounter with -ct stuff. I have since experienced lags on iOS devices and occasional dropouts on rMBP too. And just today and yesterday an unresponsive R7800. That motivated me to flash the latest and greatest stable owrt2102-r15934 but also read up on the -ct stuff and iOS devices not being as "stable" compared to the old mainline driver.
I have mostly iOS devices, so after reading your comments I downloaded the most recent firmware from kvalo's repository and copied that to /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin and rebooted. I'm going to try this combination to see how that rolls.
So far, your owrt2102-r15934 build is looking great @hnyman ; just a shoutout and a thank you for your work
FWIW, I'm discovering that the -ct driver now seems to cause trouble with the latest hostapd/mac80211 version in the 21.02 branch, as documented here:
I took all -ct out of my R7800, my current setup is mainline driver (provided by hnyman's builds as an additional download) + mainline 10.4-3.9.0.2-00142 firmware. Seems to be stable. In the past the -ct driver didn't make a difference to me, but it now does with a Mac.
FWIW, I also have 2 UniFi Lite APs running OpenWRT and on those -ct is trouble too, I run them with mainline driver + firmware and they work fine like that.
I really want to get to a stable setup and not touch it for a long time. I was hoping the stable 21.02 would be it so I can stay on that until I retire the hardware.
DSA has been dropped from the kernel 5.10 PR, so this kernel 5.10 test build is made with the traditional swconfig switch control/driver. Normal network settings work in sysupgrade from 5.4.
It's been two days since I flashed owrt2102-r15934 and only replaced the most recent firmware from kvalo's repository. I kept the -ct driver. My iOS-devices responded better with that combo. Just a half hour ago, my Mac had a connection issue. So I went ahead and did the same; install the mainline driver too, to replace the -ct driver. And because "things need to be correct" I overshot and also replaced the -ct firmware package with the mainline package, although I manually replaced that already. I only did that because I might not remember in a year what I did exactly; mix and match driver/firmware. Once I replaced the -ct firmware package with the mainline firmware package, I manually replaced the firmware-5.bin file again.
This replacing has been made a lot easier thanks to hnyman providing the mainline driver as an additional download.
I was experiencing the same problems too with a Mac, it would disconnect and not re-connect on its own, the router would disconnect it after 2 seconds for "inactivity". It's what prompted me to try the mainline driver. So far so good, but also a bit early to tell. There's also this 3.10-00047 firmware that I had good success with in the past, though not sure it's that different from 3.9.0.2 which seems to still get updates.
And indeed, thank you @hnyman for being receptive to my suggestion and providing the mainline driver as a separate ipk, it really helps those of us with -ct problems.
I'm still running on owrt2102-r15934 and I believe this release with the mainline driver and firmware I'm using is not as stable as I hoped it to be... I think I'm having spontaneous reboots after a while. I need to dig in further, but me and my partner are both working from home. So I'm more inclined to get it stable than to get to the bottom of this. Uptime is 6 minutes, the reboot happens before the cache in Spotify times out. I'm going to flash a different build in my R7800, this current build is not stable enough for me... Sadly...
--EDIT--
I'm logging the system log to my NAS, it's currently set to notice. Would setting it to informational or debug lead to a clue as to why my R7800 with this build spontaneously reboots? Or would a higher level just fill up disk space on my NAS more quickly? I haven't had the need to investigate "unstable" situations before so I'm unexperienced on that on OpenWRT, so sorry for asking a perhaps obvious question but I need this to be stable and I'm short on time as to when I can fool around during the day/evening without bothering a family member
It has been my experience that 19.07 hnyman-stable works well with non-ct driver and firmware blob (with the appropriate blob being installed via Luci software UI, not manual download+CLI). I have 3 R7800 routers running it just fine.
However, using a newer, manually downloaded blob from "master" with above setup, made WiFi go FUBAR.
It has also been my experience that 21.x hnyman-stable DOES NOT work with non-ct driver (supplied for 21.x) and firmware blob installed using the same method as above (getting blob via Luci). Maybe it will work if I got the latest blob for "master" and installed manually, but somehow I doubt it.
The truth may be that the non-ct driver and firmware just aren't properly tested past 19.x.
I think I'm having spontaneous reboots after a while. I need to dig in further, but me and my partner are both working from home. So I'm more inclined to get it stable than to get to the bottom of this.
Haven't been active here for almost 2 years or more, I'm still using OpenWrt 18.06-SNAPSHOT, r8000-ad01cb514d it works as rocks solid, I don't think 18.06.x builds from @hnyman are available anymore, but you can manually compile it if you like via git or just use ath10k on 19.07.x branch.
To replace both these files on your current firmware you need to go to:
cd /lib/firmware/ath10k/QCA9984/hw1.0
# backup original first
mkdir original
mv firmware-6.bin firmware-5.bin board-2.bin original/
# get the new firmware from linux-firmware
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/ath10k/QCA9984/hw1.0/board-2.bin
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/ath10k/QCA9984/hw1.0/firmware-5.bin
ln -s firmware-5.bin firmware-6.bin
reboot
The only thing that bothers me in this old firmware (from time to time) is the ipsec: it seems to reboot the router suddenly sometimes, it happens rarely though, but I might try new 19.07 branch with wireguard instead of ipsec to see if it's any good.
It seems though there is a lot of hassle with this new wifi driver ath10k-ct, I'm wondering why it's the default now, is there any info regarding that?
I still have a build from hnyman which is a snapshot of somewhere late in 2018, before the -ct drivers and firmware became the default in OpenWRT. That build from hnyman is rock solid indeed. Fast, stable. I decided to upgrade a few weeks ago for security reasons to a stable release (19.07.5 service release). I assumed the -ct stuff would have matured more so didn’t change anything. I did however experience lag on iOS devices.
I’ve found other posts questioning the decision by the devs to make the -ct stuff the default for ath10k and I understand the arguments in favor and opposed to that switch. The discussion about that move should not be made here. Here we discuss and appreciate hnyman’s efforts. I’ve used his builds a long time on my WNDR3700v2 and because of his open involvement here, I decided to buy a R7800 because he kept continuing releasing these great builds; download; flash; reboot; and keep on enjoying.
For the moment I'm running on the stable owrt19.07.7 build from hnyman with the mainline ath10k firmware and driver. I have removed the -ct driver and firmware. And to be complete, I've again copied the most recent firmware from kvalo's GitHub repo. It's been recently updated. We don't know what has been changed, but since it's not a new branch I'm going to assume it are bug fixes to make a seemingly more stable firmware than -ct more stable...
The last couple of times I tested the non ct firmware I had lots of issues with it. Hangs, wifi speed reduction drops. CT however works absolutely fine in my setup I usually have around 10 wifi devices connected at the same time and about 20 different devices in total that connect during the day.
And it is heavily used right now since we are all working from home.
I might give the non ct another try and see if things have changed, usually non ct has the problem, that the firmware isn't aligned with the wireless driver development, which causes the issues we have seen quite a few times. Of course you will always find a few people that have issues, but if ct would have some many issues the forum would be full of reports and I only see a handful success stories with non ct. Most likely this is due to interoperability issues with a certain client chipset driver.
For the next build, I'll bump linux firmware, thus my repo will hold latest non-ct firmware, since 19.07 ships linux firmware which includes non-ct from April 2019.
I'm trying to track down what's "off" in my configuration together with mostly Apple devices where that "off" situation is experienced. I'm running your R7800-owrt1907-r11328-81266d9001-20210327-1210-sysupgrade build at the moment, but with the non-ct driver and firmware. Stability is excellent again.
However, I'd like to find out what I might have misconfigured as there seem to be enough happy R7800 users out there that have no issues with -ct firmware and driver together with Apple devices.
From what I understand, the driver is simply kmod-ath10k-ct / kmod-ath10k. There's just the choice of picking old mainline or -ct. The part where I'm trying to get some understanding on, is the firmware. Which -ct firmware is by default in your builds? Is that:
-ct
-ct-htt
-ct-full-htt
I can't seem to find a description somehow where I can get an understanding of what's the difference between these 3 firmware variants supplied by Candela Tech?
In the Luci interface I can only find the -ct and the -ct-htt firmware variants, not the -ct-full-htt variant, although this latter one is indeed downloadable from package snapshots.
Can you please shed some light on those difference -ct firmware variant's?
So, if I understand that correctly; if I use -ct-htt, this would allow more RAM to be available to support more stations and it disables some features that the developer thinks no one is using it. But since he's not sure, he's supplying the -ct-full-htt anyway. I think I read somewhere else from this same developer from Candela Tech that using the "htt" variant would mean it's more stable in "more heavily used situations"? I don't know if he meant number of stations, that transmit a bit of data regularly. Or that he meant large amounts of data for a longer period of time?
If I combine that with this GitHub issue you linked, I would start to believe I needed to install this specific firmware version for my "stability/reliability" goal?
I believe @hnyman by default (as it's coming from master trunk) includes the -ct firmware variant, not the -ct-htt firmware variant? Am I right? I might try that -ct-htt firmware variant then.
From what I can tell by version numbering, is that the -ct-htt version I linked above from the packages snapshots is 2020-11-08-1, while the version in Luci's interface is a bit older (2020-07-02-1):
Nobody can really answer your question. It varies wildly with each env, clients, etc. The only advice I can give you is to try them all and see which one behaves best in your actual env.
I guess you're right. I've already tinkered with my /etc/config/wireless setup to remove one SSID on both radio's. I've stopped "forcing" 802.11w on the 5GHz radio and set it to optional. I've also set WPA2-PSK with CCMP to mixed WPA2/WPA3 PSK, SAE (CCMP). So far all my clients can still connect expect for an old Dell XPS13 from 2012 that's running CloudReady. That is unable to use WPA3 or 802.11w. But I can work around that with setting one SSID to WPA2-PSK and disabling 802.11w.
To make sure this tinkered setup does not affect stability, I'm going to run this for about a week or so, then I'll switch to -ct-htt firmware and -ct driver and see how that goes.
I just upgraded from 19.07 to 21.02. When I tried to install the mainline ath10k driver via luci it gave me this error:
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-ath10k found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package kmod-ath10k.
If you tried downloading the mainline driver with opkg from the OpenWrt repo, it will fail due t kernel version/checksum errors. You need to use the driver .ipk available in the download dir of each of my builds.
