State of TP-Link Archer C7v2|v5 in 2023

I've updated my first post with a link to 21.02.0-rc2 , using the same recipe for ImageBuilder like shown there.

Just a side note on my Archer C7v2's. I've seen some kernel log lines like this, related to the ath10k 5 GHz radio1. By doing a lot of tests as I own multiple devices, I found out that its a side-effect of USB 1 being not connected and USB 2 being connected to a USB Bluetooth Dongle (Belkin Bluetooth USB Stick, no BLE). If I unplug the device, those messages don't occur. I suspect its the Archer's hardware design to blame not providing enough power for the USB BT dongle.

[ 5745.145705] Rekeying PTK for STA AAA but driver can't safely do that.
[ 9342.978291] Rekeying PTK for STA AAA but driver can't safely do that.
[ 9411.995838] Rekeying PTK for STA BBB but driver can't safely do that.
[12943.878515] Rekeying PTK for STA AAA but driver can't safely do that.
[13012.966663] Rekeying PTK for STA BBB but driver can't safely do that.
[16544.686922] Rekeying PTK for STA AAA but driver can't safely do that.
[24111.145477] Rekeying PTK for STA BBB but driver can't safely do that.
[24116.243208] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[25873.512885] Rekeying PTK for STA AAA but driver can't safely do that.
[25878.526485] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[27716.844376] Rekeying PTK for STA BBB but driver can't safely do that.
[27721.960507] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[29479.216758] Rekeying PTK for STA AAA but driver can't safely do that.
[29484.243547] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[31325.576783] Rekeying PTK for STA BBB but driver can't safely do that.
[31330.749931] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[33088.007513] Rekeying PTK for STA AAA but driver can't safely do that.
[33093.034027] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[34934.269452] Rekeying PTK for STA BBB but driver can't safely do that.
[34939.286006] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[36696.582167] Rekeying PTK for STA AAA but driver can't safely do that.
[36701.827281] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[38543.050255] Rekeying PTK for STA BBB but driver can't safely do that.
[38548.080235] ath10k_pci 0000:00:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
[50551.118039] Rekeying PTK for STA AAA but driver can't safely do that.
[51163.665078] Rekeying PTK for STA AAA but driver can't safely do that.
[54151.953580] Rekeying PTK for STA AAA but driver can't safely do that.
[54269.908168] Rekeying PTK for STA BBB but driver can't safely do that.

Than you @Catfriend1 for supplying us with a running image!

Unfortunately its speed seems to be limited.
Via 5 Ghz(80HZ) im only to reach 250Mbit down.

Different, older builds would be able to go up to 500-600 Mbits. Is there anything we can do?
best & thank you again !

btw Software flow offloading is activated and im running your latest rc3 image

1 Like

Which type of encryption / scenario do you use? Multi Ssid?

Yes, i use multiple SSIDs, both on the 2,4 & 5 Ghz band. only a couple of devices in use.
Encryption is WPA2 PSK (CCMP)

Does this have something to do with the speed?
Sorry im a noob, dont know much about networking.

Does this help?

yes, see Overall slow 2.4 GHz WiFi on OpenWrt devices - #26 by ACwifidude

1 Like

This is a very crowded enviroments with lots of differents wiFis across the spectrum.
For testing purposes, i've also disabled all but 1 SSIDs.

Funny thing is: The modem/router from my isp gives me constant speed upwards of 500 mbits on the same 5 Ghz channels (80 width) during testing...
Is there anything else we can do to speed up the Archer?

Hmm I don't know, getting my ~ 500 Mbits here with a dumb AP via LAN server. (my wan cannot provide such high data rates, lan can).

Maybe try completely disabling ipv6 in /etc/sysctl.conf. That gave my whole network a boost I didn't understand because every other component was configured ipv6 off.

fyi: I've updated my first post to include OpenWrt 21.02.0-rc4 with @sammo 's "iw phy phy1 set txq memory_limit 8388608" fix to be tested.

1 Like

thanks Catfriend1

1 Like

Hi all,

I have an Archer C7 V5 running 21.02-rc4. I am seeing messages in the system log about "firmware crashed" followed by "device successfully recovered" every couple of days. Wifi seems fine and I haven't noticed any disconnects or drops in service.

Has anyone else noticed this?

Thanks

Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.666428] ath10k_pci 0000:00:00.0: firmware crashed! (guid 61f8daa6-7918-4497-b34e-557e3678ef50)
Sun Aug  8 14:04:14 2021 kern.info kernel: [69875.675871] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
Sun Aug  8 14:04:14 2021 kern.info kernel: [69875.685503] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
Sun Aug  8 14:04:14 2021 kern.info kernel: [69875.697802] ath10k_pci 0000:00:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c
Sun Aug  8 14:04:14 2021 kern.info kernel: [69875.727824] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
Sun Aug  8 14:04:14 2021 kern.info kernel: [69875.735409] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.745324] ath10k_pci 0000:00:00.0: firmware register dump:
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.751193] ath10k_pci 0000:00:00.0: [00]: 0x4100016C 0x00000000 0x0099483D 0x930F9A72
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.759404] ath10k_pci 0000:00:00.0: [04]: 0x0099483D 0x00060130 0x00000000 0x00000001
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.767607] ath10k_pci 0000:00:00.0: [08]: 0x00000000 0x009BB400 0x00426CE0 0x0042C43C
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.775865] ath10k_pci 0000:00:00.0: [12]: 0x00000009 0x00000000 0x0095808C 0x009580A2
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.784132] ath10k_pci 0000:00:00.0: [16]: 0x00958080 0x0094085D 0x00000000 0x00000000
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.792381] ath10k_pci 0000:00:00.0: [20]: 0x4099483D 0x0040AC34 0x00000002 0x004F9A62
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.800608] ath10k_pci 0000:00:00.0: [24]: 0x80995012 0x0040AC94 0x00000000 0xC099483D
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.808867] ath10k_pci 0000:00:00.0: [28]: 0x809960A0 0x0040AD14 0x0041E524 0x00426CE0
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.817081] ath10k_pci 0000:00:00.0: [32]: 0x80997EC9 0x0040ADB4 0x0041E524 0x00426CE0
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.825326] ath10k_pci 0000:00:00.0: [36]: 0x809AF249 0x0040AEE4 0x004259F8 0x00000002
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.833605] ath10k_pci 0000:00:00.0: [40]: 0x80940F18 0x0040AF14 0x00000005 0x004039E4
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.841867] ath10k_pci 0000:00:00.0: [44]: 0x80940EEA 0x0040AF44 0x00400000 0x00000000
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.850097] ath10k_pci 0000:00:00.0: [48]: 0x80940F31 0x0040AF64 0x00401C10 0x00400600
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.858333] ath10k_pci 0000:00:00.0: [52]: 0x40940024 0x0040AF84 0x004068E8 0x004068E8
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.866532] ath10k_pci 0000:00:00.0: [56]: 0x00000000 0x0040AFA4 0x009BB001 0x00040020
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.874784] ath10k_pci 0000:00:00.0: Copy Engine register dump:
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.880946] ath10k_pci 0000:00:00.0: [00]: 0x00057400   7   7   3   3
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.887620] ath10k_pci 0000:00:00.0: [01]: 0x00057800   4   4   6   7
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.894288] ath10k_pci 0000:00:00.0: [02]: 0x00057c00  59  59  58  59
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.900953] ath10k_pci 0000:00:00.0: [03]: 0x00058000   8   8  10   8
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.907623] ath10k_pci 0000:00:00.0: [04]: 0x00058400 1155 1155 107  67
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.914465] ath10k_pci 0000:00:00.0: [05]: 0x00058800  26  26  25  26
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.921131] ath10k_pci 0000:00:00.0: [06]: 0x00058c00  26  26  26  26
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.927798] ath10k_pci 0000:00:00.0: [07]: 0x00059000   0   0   0   0
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69875.934732] ath10k_pci 0000:00:00.0: debug log header, dbuf: 0x411a98  dropped: 0
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69875.942576] ath10k_pci 0000:00:00.0: [0] next: 0x411ab0 buf: 0x40f8fc sz: 1500 len: 212 count: 8 free: 0
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.952463] ath10k_pci 0000:00:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.958874] ath10k: [0000]: 2AE34304 025C0014 4CF84300 488B9B00 6EB545B2 A9E10000 01000000 2AE34304
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.968228] ath10k: [0008]: 574C0010 88991071 908A4300 00B49B00 11000000 2AE34304 574C0014 908A4300
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.977580] ath10k: [0016]: 80CE4300 00000000 0C000000 8E1D0000 2AE34304 574C0014 908A4300 48B49B00
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.986937] ath10k: [0024]: 13000000 00000000 223D0000 2AE34304 574C0014 908A4300 90B49B00 06000000
Sun Aug  8 14:04:14 2021 kern.err kernel: [69875.996383] ath10k: [0032]: 0C000000 023D0000 2AE34304 574C0010 88991071 908A4300 D8B49B00 10000000
Sun Aug  8 14:04:14 2021 kern.err kernel: [69876.005766] ath10k: [0040]: 2AE34304 4B4C0010 6A492108 00003C84 21080000 3C846A49 2AE34304 0100FC17
Sun Aug  8 14:04:14 2021 kern.err kernel: [69876.015184] ath10k: [0048]: 00000000 A7190000 24AB4000 6C010041 FFFF0F00
Sun Aug  8 14:04:14 2021 kern.err kernel: [69876.022143] ath10k_pci 0000:00:00.0: ATH10K_END
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.026914] ath10k_pci 0000:00:00.0: [1] next: 0x411a98 buf: 0x40feec sz: 1500 len: 0 count: 0 free: 0
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.041728] ath10k_pci 0000:00:00.0: failed to set preamble for vdev 0: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.049181] ath10k_pci 0000:00:00.0: failed to set mgmt tx rate -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.071457] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.084617] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.098520] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.131746] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.142864] ath10k_pci 0000:00:00.0: failed to send wmi nop: -143
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.149318] ath10k_pci 0000:00:00.0: could not request stats (type -268435456 ret -143 specifier 1)
Sun Aug  8 14:04:14 2021 kern.warn kernel: [69876.159150] ath10k_pci 0000:00:00.0: removing peer, cleanup-all, deleting: peer c406c08a vdev: 0 addr: 3c:84:6a:49:21:08
Sun Aug  8 14:04:14 2021 kern.info kernel: [69876.271109] ieee80211 phy0: Hardware restart was requested
Sun Aug  8 14:04:15 2021 kern.warn kernel: [69877.215578] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 4  peers: 128  tid: 256
Sun Aug  8 14:04:15 2021 kern.info kernel: [69877.232244] ath10k_pci 0000:00:00.0: wmi print 'P 129 V 8 T 411'
Sun Aug  8 14:04:15 2021 kern.info kernel: [69877.238551] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424  sw-crypt: 0 ct-sta: 0'
Sun Aug  8 14:04:15 2021 kern.info kernel: [69877.246861] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 24512 iram: 41204'
Sun Aug  8 14:04:15 2021 kern.warn kernel: [69877.309836] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
Sun Aug  8 14:04:15 2021 kern.warn kernel: [69877.318655] ath10k_pci 0000:00:00.0: set-coverage-class, phyclk: 88  value: 0
Sun Aug  8 14:04:15 2021 kern.info kernel: [69877.327230] ath10k_pci 0000:00:00.0: rts threshold -1
Sun Aug  8 14:04:16 2021 kern.info kernel: [69878.334436] ath10k_pci 0000:00:00.0: device successfully recovered

@chadneufeld Sorry ,you did not use my build with the non-ct drivers.:frowning: . Your log says you've used some other image with ct drivers.

I'm using DAWN, 802.11r/k/v and the full-htt version of the Ath10k driver; ath10k-firmware-qca988x-ct-full-htt on 3 access points with roaming.

I thought the non-ct version didn't support r/k/v as well as the full-htt? Do you know if that's true?

I can try switching to the non-ct version.

1 Like

I don't know. Had it on my list for long to take a look at dawn. Until now, I'm just doing dirty band forcing by blocking macs on my 2.4 ghz ssid and allowing them on the 5ghz one.

Thanks for the help.

I do know that -ct firmware doesn't support r/k/v operation as the wifi refuses to start. Both the non-ct and ct-full-htt seem to support r/k/v. Wifi starts up with both firmware versions.

I'm only running 5 GHz but with 3 access points. I'm not worried about band-steering from 2.4 to 5 GHz but I want to have seamless roaming and switching between the different access points. I did a bunch of testing today and my subjective opinion is that roaming between access points is better with the ...-ct-full-htt firmware. Roaming worked okay with the non-ct but the switch to a new access point took much longer.

The firmware never crashed with the non-ct drivers. The firmware crash might be an issue with the ct-full-ht firmware. The interesting thing is that even with firmware crashes, I never actually lose Wifi like a lot of people do with the Archer C7s.

1 Like

@chadneufeld Very interesting to hear this... thanks for telling us :slight_smile:

Confirmed, I believe. After roughly 20 years of a WRAP board serving my humble needs I got me brand new v5, installed 19.07.8 and found the 5Ghz band stall on me consistently after half a day of service or so. Replaced the -ct packages as described above, and it's been "smooth sailing" for 2 days now.

1 Like

Hi everyone,

After 10+ years with dd-wrt, I bit the bullet and moved my Archer C7 v2 to openwrt. First time with openwrt over here and very excited with getting 21.02-rc4 going. I got ipv6 and sqm up in no time along with my pihole setup (running in docker in a LAN NAS) and all was going perfectly: it was such a pleasure to see kernel 5.4 purring in this hardware.

While trying to figure out the performance boundaries, I first moved from ath10k-firmware-qca988x-ct/kmod-ath10k-ct firmware/driver to non-ct firmware/driver and saw some improvement on WLAN↔︎LAN iperf3 bandwidth to the NAS. On the WAN side, sqm got my connection in ship shape and pass the dslreports' bufferbloat testing with flying colors.

As things were going well, I went ahead and installed banip, vnstat, and statistics to see where it broke. And broke it did: overnight things went south with lots of oom-kill action, the last of which killed hostapd. That was probably responsible for a no-wifi wake-up call.

Since then, I uninstalled the three packages I was trying out and set vm.min_free_kbytes to 1024 as it was 16 MB.

Because of the memory situation, esp. since there is no swap, I was wondering why uhttpd (luci) is kept running all the time and is not launched on demand by the likes of inetd.

Any other hints/tips for using the Archer C7 v2 as a home router where the WAN is a measly 10/1 Mbit/s ADSL but LAN↔︎WLAN should be able to move 400 Mbit/s are more than welcome!

1 Like

I love you

1 Like

Sounds like you're doing pretty good on your own...

Possibly playing with the more advanced settings on Cake SQM, (read down the 3 layers of SQM docs on the main OpenWrt site) to squeeze out a bit more performance and fairness results. One thing you would probably benefit from would be the ack-filtering on egress, reducing some traffic load on that 1Mbit upload.