State of TP-Link Archer C7v2|v5 in 2023

Catfriend1 · 2021-07-01T15:53:09.388Z

ErnstBloch:

Different, older builds would be able to go up to 500-600 Mbits. Is there anything we can do?

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

ErnstBloch · 2021-07-01T18:52:42.964Z

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?

Catfriend1 · 2021-07-02T06:09:32.000Z

ErnstBloch:

Does this have something to do with the speed?

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

ErnstBloch · 2021-07-07T09:23:47.669Z

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?

Catfriend1 · 2021-07-07T13:44:49.445Z

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.

Catfriend1 · 2021-08-06T09:31:21.788Z

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.

m00ki3 · 2021-08-06T09:38:42.998Z

thanks Catfriend1

chadneufeld · 2021-08-09T01:20:21.751Z

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

Catfriend1 · 2021-08-09T15:02:36.865Z

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

chadneufeld · 2021-08-09T15:24:14.787Z

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.

Catfriend1 · 2021-08-09T17:16:09.326Z

chadneufeld:

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 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.

chadneufeld · 2021-08-10T02:51:57.029Z

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.

Catfriend1 · 2021-08-10T20:06:40.018Z

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

rwberger · 2021-08-14T22:49:54.572Z

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.

adavid · 2021-08-16T08:08:28.562Z

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!

cal3b · 2021-08-23T06:28:14.541Z

I love you

JonP · 2021-08-31T21:06:47.004Z

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.

adavid · 2021-09-01T18:19:52.320Z

JonP:

[...] ack-filtering on egress, reducing some traffic load on that 1Mbit upload.

Thanks. After some sleuthing, I added option eqdisc_opts 'nat dual-srchost ack-filter' but I am not sure it made a big difference in dslreports.com. It was cool to learn why it is important on very asymmetric links.

One thing that I have been wondering is the link layer adaption per packet overhead, but that would require a good bout of measuring ping times so I'm leaving it at 44 for the time being.

JonP · 2021-09-01T21:54:48.220Z

Yep... I'd add nat dual-dsthost ingress on the ingress side, to have the same kind of flow fairness behavior in both directions. I don't know if the ingress keyword is going to help much or not, but it's suggested.

Tuning the shaping speeds, of course, to find the maximums before the bloat starts to rise is the main thing, seeing where your sweet spot is for the link adaptation less so, but still worth it at some point.

You could use tc -s qdisc on the command line, to see a reporting of how Cake is configured and what it's doing, (and that you didn't do a typo in the optional lines, causing it not to set up an interface at all!) including how many acks are filtered.

adavid · 2021-09-02T05:49:38.749Z

JonP:

Yep... I'd add nat dual-dsthost ingress on the ingress side,

Yup, that went in along with the egress options I mentioned.

JonP:

You could use tc -s qdisc on the command line, to see a reporting of how Cake is configured and what it's doing, (and that you didn't do a typo in the optional lines, causing it not to set up an interface at all!) including how many acks are filtered.

I did check that while setting things up and several hours later, I can see the effect of ack-filter:

                   Bulk  Best Effort        Voice
  thresh       59368bit      950Kbit    237496bit
  target          307ms       19.2ms       76.7ms
  interval        614ms        114ms        172ms
  pk_delay          0us       13.6ms        9.4ms
  av_delay          0us       7.88ms       1.53ms
  sp_delay          0us       1.24ms         95us
  backlog            0b        1393b           0b
  pkts                0      6259880        52208
  bytes               0    677996170      7181345
[...]
  ack_drop            0      1155234            0
[...]

It does not look bad to me (~18% of packets!), but it's still a little arcane.