Experience with ath10k CT firmware/driver vs original firmware/driver

Hello, I have been using and compiling my own LEDE (and previously OpenWRT) for my Archer C7 v2. I have had some issues with my 5GHz WiFi, with clients regularly losing connection and reconnecting. I also tried some newer ath10k firmware from kvalos repository: 10.2.4.54 is the LEDE default at this time, I also tried 10.2.4.56, .58 and .59-2. So far, .54 is the most stable one for me.

Now, my question is: What is your experience with the CT firmware/driver for ath10k working in real life? Right now I have just compiled an image and I am testing it. So far it works ok. However, do I miss anything in functionality compared to the original firmware (since CT firmware is based on 10.1 instead of 10.2)? What advantages do I get from running CT firmware? I don't use IBSS mode, only AP.

Well, that was a short-lived experiment. While at first everything seemed to work, my stations got disconnected when doing large transfers (within 1 minute if it was a large file transfer from/to a machine in the local LAN). The basic error message is:

root@router ~# logread|grep missing
Wed Dec 14 14:00:52 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:05:47 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:24:48 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:25:48 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:26:18 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:26:54 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Dec 14 14:27:21 2016 daemon.info hostapd: wlan0: STA 5c:93:a2:9b:e4:67 IEEE 802.11: disconnected due to excessive missing ACKs

Further, the log is spammed with debug messages like these, is there a way to turn these off?

Wed Dec 14 16:29:19 2016 kern.debug kernel: [ 9296.976437] ath10k_pci 0000:01:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Wed Dec 14 16:29:19 2016 kern.debug kernel: [ 9296.982737] ath10k: [0000]: 42589100 284C0008 40000000 03000000 49589100 234CFC0F 01000000 01000000
Wed Dec 14 16:29:19 2016 kern.debug kernel: [ 9296.991924] ath10k: [0008]: 01000000
Wed Dec 14 16:29:19 2016 kern.debug kernel: [ 9296.995551] ath10k_pci 0000:01:00.0: ATH10K_END
Wed Dec 14 16:29:21 2016 kern.debug kernel: [ 9298.976594] ath10k_pci 0000:01:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Wed Dec 14 16:29:21 2016 kern.debug kernel: [ 9298.982909] ath10k: [0000]: F5609100 284C0008 40000000 03000000 FC609100 234CFC0F 01000000 01000000
Wed Dec 14 16:29:21 2016 kern.debug kernel: [ 9298.992119] ath10k: [0008]: 01000000 12619100 284C0008 40000000 03000000 18619100 234CFC0F 01000000
Wed Dec 14 16:29:21 2016 kern.debug kernel: [ 9299.001299] ath10k: [0016]: 01000000 01000000
Wed Dec 14 16:29:21 2016 kern.debug kernel: [ 9299.005717] ath10k_pci 0000:01:00.0: ATH10K_END

So I decided to restore my image with the regular ath10k driver and firmware back on. I noticed in LUCI that the tx-rate is displayed with ath10k-CT-firmware, but I can live without that if the connection is at least stable.

The main upside I see with the CT firmware is that there is a person which is at least able to address reported issues.
Other then that it supports a few goodies that the vendor firmware doesn't have.

I also have Ath10k issues on my Archer C7. Are the issues you are experiencing similar to mine, which are described in the following thread: Ath10k Issues on LEDE

Note that nbd gave a link to his staging tree which includes some Ath10k fixes. I will try that build tomorrow to see if that solves my issues.

I have noticed that changing a setting on my wireless NIC in my laptop (QCA61x4, Windows 10, driver version 12.0.0.279) improves reliability quite a lot: I disabled "Dynamic MIMO Power Save". Things aren't perfect, but a lot less "excessive missing acks". I set "disassoc_low_ack" to 0 to test a bit further.

I never had any problems with my mobile phones though (3 iphones on 5GHz network). Also did not have any complete freezes on WiFi.

Hey @avbohemen, sorry for bringing up an old topic... But I noticed you have a QCA61x4, and an Archer C7. Is the QCA61x4 you are using a Killer NIC (Dell XPS 9630? Acer Swift 3?, etc)?

In case you do not know, if you are using a Killer NIC (12.0.0.279). Killer released updated drivers (12.0.0.296) which apparently fix the disconnection with large file transfers issue. They may help ya.

Other than that, you haven't experienced your router crashing with your QCA61x4 NIC when transferring large files under load? With my Killer 1535 NIC transferring a large file to another LAN machine, and running a speed test during will crash my Archer C7v2 router.

What firmware are you using? Still 10.2.4.54? Or did you upgrade to the latest 10.2.4-1.0? Or tried the -ct one? If your QCA61x4 is a Killer NIC, I would be very interested in your setup. "Dynamic MIMO Power Save" is already disabled (by default I assume) in my 12.0.0.296 wifi drivers. My current LEDE is (LEDE Reboot SNAPSHOT r3025-c99f881), and it's on the default "10.2.4-1.0" firmware.

Hi codster314,
Officially, my NIC is not a killer 1535, even though it uses the same driver. In Windows 10, it simply says "Qualcomm Atheros QCA61x4 Wireless Network Adapter". My laptop is an Acer Aspire VN7-791G. At the moment, I am using the 12.0.0.296 driver, and it also needs "disassoc_low_ack = 0" to keep a stable connection. Funny thing is, with driver version 12.0.0.285, I could remove that setting and still keep a stable connection.

My Archer C7v2 is currently running the "regular" firmware and driver, not the Candelatech version. However, I do use a non-official firmware version, from https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA988X/hw2.0/ Currently I am at 00024, but I see just now that 00025 is available, I will test that as soon as I have some time. My LEDE version is SNAPSHOT, r3436-90728c7.

Just wondering, if it's a reason good enough to make CT firmware default rather than Atheros' official?

Cheers.