Ath10k-firmware-qca988x updates brakes 2,4GHz WiFi on TP-Link Archer C7 v2

fa11enangel · January 13, 2019, 5:07pm

After updating the firmware on my TP-Link Archer C7 v2 I get a lot of packet losses on 2,4 GHz WiFi network.

My Setup:

TP-Link Archer C7 v2 Router
OpenWRT 18.06.1 with all updates installed (27.12.2018)

device information:

[ 14.475922] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 14.479112] ieee80211 phy1: Atheros AR9550 Rev:0 mem=0xb8100000, irq=47

Atheros related dmesg information:

   12.236742] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
[   12.511845] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
[   12.522727] ath10k_pci 0000:01:00.0: Falling back to user helper
[   12.647360] firmware ath10k!pre-cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[   12.760070] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-6.bin failed with error -2
[   12.770955] ath10k_pci 0000:01:00.0: Falling back to user helper
[   12.872226] firmware ath10k!QCA988X!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
[   12.885591] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[   12.894984] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[   12.907999] ath10k_pci 0000:01:00.0: firmware ver 10.2.4-1.0-00033 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 c41417d0
[   13.004699] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   13.015343] ath10k_pci 0000:01:00.0: Falling back to user helper
[   13.087187] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[   13.117538] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   14.209981] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1
[   14.349309] ath: EEPROM regdomain: 0x0
[   14.349315] ath: EEPROM indicates default country code should be used
[   14.349318] ath: doing EEPROM country->regdmn map search
[   14.349330] ath: country maps to regdmn code: 0x3a
[   14.349334] ath: Country alpha2 being used: US
[   14.349337] ath: Regpair used: 0x3a
[   14.459917] ath: EEPROM regdomain: 0x0
[   14.459924] ath: EEPROM indicates default country code should be used
[   14.459927] ath: doing EEPROM country->regdmn map search
[   14.459939] ath: country maps to regdmn code: 0x3a
[   14.459943] ath: Country alpha2 being used: US
[   14.459946] ath: Regpair used: 0x3a
[   25.778224] ath: EEPROM regdomain: 0x8114
[   25.782292] ath: EEPROM indicates we should expect a country code
[   25.788499] ath: doing EEPROM country->regdmn map search
[   25.793882] ath: country maps to regdmn code: 0x37
[   25.798751] ath: Country alpha2 being used: DE
[   25.803253] ath: Regpair used: 0x37
[   25.806897] ath: regdomain 0x8114 dynamically updated by user
[   25.812978] ath: EEPROM regdomain: 0x8114
[   25.817042] ath: EEPROM indicates we should expect a country code
[   25.823248] ath: doing EEPROM country->regdmn map search
[   25.828639] ath: country maps to regdmn code: 0x37
[   25.833490] ath: Country alpha2 being used: DE
[   25.837996] ath: Regpair used: 0x37
[   25.841544] ath: regdomain 0x8114 dynamically updated by user

WiFi configuration is:

wlan0     ESSID: "wifi5G"
          Access Point: 11:22:33:44:55:66
          Mode: Master  Channel: 36 (5.180 GHz)
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -101 dBm
          Bit Rate: unknown
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

wlan1     ESSID: "wifi2G"
          Access Point: 11:22:33:44:55:67
          Mode: Master  Channel: 9 (2.452 GHz)
          Tx-Power: 17 dBm  Link Quality: 59/70
          Signal: -51 dBm  Noise: -95 dBm
          Bit Rate: 35.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1

After installing the following update, my 2,4GHz wifi got unstable:

ath10k-firmware-qca988x - 2018-04-19-71e50312-1 - 2018-05-12-952afa49-1

I get packet losses about 40-80% dependent on device and network load. The 5GHz networking is working fine.

First I have a question. Why the update version was named "2018-05-12-952afa49-1" (firmware date) but was released on December 27, 2018. Such uncommon naming makes it really hard to find the issue which was caused by the update, because it is dated to 2018-05-12 but was released 2018-12-27.

Also all ath10k firmware versions were updated with this date at once:

|ath10k-firmware-qca4019-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|425.5 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca4019-ct_2018-05-12-952afa49-1_mips_24kc.ipk|425.7 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca4019_2018-05-12-952afa49-1_mips_24kc.ipk|457.7 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca6174_2018-05-12-952afa49-1_mips_24kc.ipk|846.7 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca9887-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|187.8 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca9887-ct_2018-05-12-952afa49-1_mips_24kc.ipk|188.0 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca9887_2018-05-12-952afa49-1_mips_24kc.ipk|203.0 KB|Thu Dec 27 20:16:35 2018|
|ath10k-firmware-qca9888-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|444.9 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca9888-ct_2018-05-12-952afa49-1_mips_24kc.ipk|445.1 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca9888_2018-05-12-952afa49-1_mips_24kc.ipk|493.1 KB|Thu Dec 27 20:16:35 2018|
|ath10k-firmware-qca988x-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|181.8 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca988x-ct_2018-05-12-952afa49-1_mips_24kc.ipk|182.0 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca988x_2018-05-12-952afa49-1_mips_24kc.ipk|214.0 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca9984-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|448.3 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca9984-ct_2018-05-12-952afa49-1_mips_24kc.ipk|448.6 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca9984_2018-05-12-952afa49-1_mips_24kc.ipk|488.2 KB|Thu Dec 27 20:16:36 2018|
|ath10k-firmware-qca99x0-ct-htt_2018-05-12-952afa49-1_mips_24kc.ipk|419.6 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca99x0-ct_2018-05-12-952afa49-1_mips_24kc.ipk|419.6 KB|Thu Dec 27 20:16:37 2018|
|ath10k-firmware-qca99x0_2018-05-12-952afa49-1_mips_24kc.ipk|366.3 KB|Thu Dec 27 20:16:36 2018|

As dmesg was without any related runtime errors, how can I help you to find the issue. Restarting WiFi by calling the command "wifi" or rebooting the router fixed the issue for about 1-2 days. The wifi has about 10 connected devices on 2,4 GHz with little to no load as the wifi is only used to connect mobile devices to the internet. Only one MacBook is connected to 5 GHz wifi.

Returning to old firmware version fixed the issue and now it is stable again.

I think this can be a release issue for v18.06.2 (taken from https://openwrt.org/releases/18.06/changelog-18.06.2):
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=2e7e60f2d6ebbc54dd2131ff10afdd8f8eab43f5

I'll test the current firmware version which is not "firmware-5.bin_10.2.4-1.0-00037" (see commit link above) but is "firmware-5.bin_10.2.4-1.0-00043" and can be found here: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware or directly linked here: https://github.com/kvalo/ath10k-firmware/tree/master/QCA988X/hw2.0/10.2.4-1.0

silentcreek · January 14, 2019, 9:30pm

Are you really sure your 2.4GHz wifi breaks with the firmware? Not your 5GHz wifi? Because the ath10k driver and firmware is actually only used by the 5GHz radio. The 2.4GHz radio in your Archer C7 v2 uses a different driver with no extra firmware binary (ath9k).

In addition: What does logread show when the wifi doesn't work anymore? hostapd might give you a clue what's going on.

As for the date string in the package name. That merely refers to the date of the sources that were used to build this package. The file modification date you see is merely the date when the package was built. Basically, file modification dates have no meaning at all. What you are interested in, is the version number or the date of the source code that was used.

Just imagine the following example: The bootloader software u-boot is used in several distributions (including OpenWrt). Their versioning is based on dates (year and month). Say, the project releases a version 2019.1. Then you have a distribution like Fedora or Arch that usually integrates new software quickly. So they will soon integrate the new software into their own sources and start shipping packages, maybe even within the same month. On the other hand, you have more conservative distributions such as Debian or CentOS. They want to test the software for a longer period before they ship it to users. So, you can have half a year or longer go by, by the time this version of u-boot will be released to users of such more conservative distributions. If both of these projects would name the package after the month they released the package, the conservative distribution would have a package name like u-boot-2019-06-01 and people might think, hey, my code is newer. But it's still the same code that u-boot released as 2019.1. So, it makes no sense to do so.

What is a little more confusing in your case is that the date in the name of your package has no relationship to the versioning scheme the developers of that firmware use themselves for naming the firmware version, which is firmware-5.bin_10.2.4-1.0-00037. This is due to the fact that multiple firmware binaries come from the same source tree. So, when the firmware of a device A is updated, you need to get the sources with a newer date which will bump the package version. But the firmware for device B from the same source tree might still be the same, yet since they are in the same package, the date is bumped as well. That's a bit unfortunate. But this happens in other distributions as well and is necessary if you don't want to create a new package for every single firmware.

fa11enangel · January 14, 2019, 9:51pm

Yes it brakes 2,4 GHz and I know that ath9k is responsible for 2.4GHz and ath10k for 5GHz. That was the last change on the router as it worked before like a charm. Going back with the firmware helped instantly.

I'll try to track it down with firmware-5.bin_10.2.4-1.0-00037 and will post the logs.

fa11enangel · January 19, 2019, 10:32am

I've tried the newest firmware firmware-5.bin_10.2.4-1.0-00043 but the error came back after 5 days.

There are no direct channel overlap with other wifis. Running command "wifi" or rebooting the router fixes the problem for several days. logread says nothing special. Only connecting and disconnecting devices due to inactivity (mobile phones). I've added the logs while the error existed. The clients got connected and then disconnected again. I've replaced the corresponding mac address with "00:11:22:33:44:55":

Fri Jan 18 20:57:40 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: authenticated
Fri Jan 18 20:57:40 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: associated (aid 4)
Fri Jan 18 20:57:40 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:11:22:33:44:55
Fri Jan 18 20:57:40 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 WPA: pairwise key handshake completed (RSN)
Fri Jan 18 20:57:48 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:11:22:33:44:55
Fri Jan 18 20:57:48 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: disassociated
Fri Jan 18 20:57:49 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: authenticated
Fri Jan 18 20:57:49 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: associated (aid 4)
Fri Jan 18 20:57:49 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:11:22:33:44:55
Fri Jan 18 20:57:49 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 WPA: pairwise key handshake completed (RSN)
Fri Jan 18 20:57:57 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:11:22:33:44:55
Fri Jan 18 20:57:57 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: disassociated
Fri Jan 18 20:57:58 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: authenticated
Fri Jan 18 20:57:58 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: associated (aid 4)
Fri Jan 18 20:57:58 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:11:22:33:44:55
Fri Jan 18 20:57:58 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 WPA: pairwise key handshake completed (RSN)
Fri Jan 18 20:58:27 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:11:22:33:44:55
Fri Jan 18 20:58:27 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: disassociated
Fri Jan 18 20:58:28 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: authenticated
Fri Jan 18 20:58:28 2019 daemon.info hostapd: wlan1: STA 00:11:22:33:44:55 IEEE 802.11: associated (aid 4)
Fri Jan 18 20:58:28 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:11:22:33:44:55

Also The clients get an ip address from dhcp-server (dnsmasq) while connecting to wifi. What can I do to track the error more closely. I went back to firmware-0033. Maybe it'll happen too.

opaav · January 22, 2019, 2:36am

Which one is the latest for C7 v2?

I see a newer one here:

10.2.4.70 QCA988X hw2.0: 10.2.4.70: add firmware-5.bin_10.2.4.70.69

direct link:
https://github.com/kvalo/ath10k-firmware/blob/2447f4d17fddcfd916fa93c7ce528d6a51d2f535/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.69

fa11enangel · January 22, 2019, 8:13pm

The versioning ist done pretty strange. I've aligned with the version which is used in OpenWRT:

and took the newer version for testing.

opaav · January 23, 2019, 2:09am

Yes it seems both folders are quite recent:

[10.2.4-1.0] update in Nov 2018
[10.2.4.70] update in Dec 2018

I trying 10.2.4.70.69, it appears to work and dmesg show

[ 13.641579] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.69 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 edfb196a

I want to see if new firmware fix my 5 Ghz problem, it will show many ath10x kernel.warnings and after a few days people will complain wifi slow, then I need to reboot or wifi restart to fix.

Keltere · May 8, 2019, 7:45pm

I can confirm this problem on my custom x86 device too.
I have a Compex wifi card for 5ghz with ath10k and an external usb alpha with ath9k for 2.4ghz.
Did you guys found any solution? I'm using last stable version with openwrt.