TP-Link Archer c2600 running poorly from 21.02 and onwards

Installing and Using OpenWrt
1

Using a tp link archer c2600 on openwrt as an accesspoint, it runs pretty stable on 19.7.8. Both 2.4 and 5ghz never go down, the router itself is running stable for 100+ days now.

Only when i update to 20.* the device becomes unusable. The 2.4ghz radio goes down frequently. I notice this because my wireless internet radio on 2.4ghz constantly stops playing (this is very frustrating!!), which made me to go back in to 19.7.8 . After downgrading the c2600 runs pretty stable.

I would like to run the latest stable release , being 21.02.1. But at this point the 2.4ghz is just too unreliable on the latest stable release.

I'm wondering: where there fundamental changes made between 19.7.8 and 21.02? (because on 21.02, the problems began to occur). Maybe a different wireless driver, newer kernel, or other "improvements"?

I tried setting cpu scaling governor on the 21.02 release but this didnt change anything with the 2.4ghz constantly dropping.

Anyone who can help . Is there anyone who runs 21.02.1 without issues on the c2600? ( and how to achieve this?)

2

All of those.

3

Still using 19.07.3, because it appears to be the most stable release.

Mine run as APs though

image

1 Like
4

Strange, I have two of those and they are rock solid with 21.02.1:
Uptime: 75d 2h 57m 57s
RX: 592.86 GB (821535880 Pkts.)
TX: 984.69 GB (1219297946 Pkts.)
I've not changed the wireless driver, both networks are set with WPA2 PSK (CCMP) with automatic channel selection and there are around 20 devices connected during the day. There are no additional packages installed and the only changes I've introduced is the country.
Occasionally, I see these error messages in the kernel log, but the wireless is pretty stable:
[ 3729.206213] ath10k_pci 0000:01:00.0: htt tx: fixing invalid VHT TX rate code 0xff

5

I too use the c2600 as an access point. on 21.02.1 , openwrt doesnt crash, it stays alive. The only problem i can observe is the 2.4ghz wireless crapping out. On the 5ghz radio, there seems to be no issue (no drops in connection whatsoever).

If i'm right, the c2600 is based on the qualcomm atheros ipq8064 platform, with both the 2.4ghz and 5ghz radio being the qca9980 chip, which is a 4x4 abgn-ac dual radio solution.

The wireless driver for the qca9980 seems to be the ath10k or ath10k-ct driver in 20.02.1, i can't find which driver is being used by default (they both are mentioned in the changelog).

I found this thread suggesting others experienced problems with ath10k-ct on the c2600 device. Up until closure of the thread back in 2019.

I'm wondering how to proceed; as mentioned i would like to use the c2600 with the latest openwrt release. If im right, the preferred qca9980 driver of choice seems to be ath10k-ct. If this is true, this raises the question: if so many users experience issues with ath10k-ct, is there a way to fix what is causing these issues? I'm no expert in these matters in any way, so other then logs and a dmesg there isnt much else i can contribute.

And if the c2600 seems to be the troublemaker, is there a 4x4 qualcomm atheros based device that is rocksolid on 21.02.1 (ath10k-ct?)

6

For me, ath10k-ct didn't have any positive impact on stability, running 19.07.

7

It seems 19.7.8, which i am now on, uses the ath10k driver (non -ct) but is "optimized for CT firmware".

Altough the c2600 seems to run fine, it looks like loading of firmware while booting, there are things going wrong?

[   12.694179] ath10k_pci 0000:01:00.0: assign IRQ: got 66
[   12.694201] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x40.
[   12.694608] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[   12.701059] ath10k_pci 0000:01:00.0: enabling bus mastering
[   12.701522] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   12.874996] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/fwcfg-pci-0000:01:00.0.txt failed with error -2
[   12.875041] ath10k_pci 0000:01:00.0: Falling back to user helper
[   13.040829] firmware ath10k!fwcfg-pci-0000:01:00.0.txt: firmware_loading_store: map pages failed
[   13.041040] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
[   13.048786] ath10k_pci 0000:01:00.0: Falling back to user helper
[   74.713408] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
[   74.713451] ath10k_pci 0000:01:00.0: Falling back to user helper
[   82.210156] firmware ath10k!cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[   82.213622] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/ct-firmware-5.bin failed with error -2
[   82.217676] ath10k_pci 0000:01:00.0: Falling back to user helper
[   82.244634] firmware ath10k!QCA99X0!hw2.0!ct-firmware-5.bin: firmware_loading_store: map pages failed
[   82.244831] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/ct-firmware-2.bin failed with error -2
[   82.252908] ath10k_pci 0000:01:00.0: Falling back to user helper
[   82.281409] firmware ath10k!QCA99X0!hw2.0!ct-firmware-2.bin: firmware_loading_store: map pages failed
[   82.281606] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/firmware-6.bin failed with error -2
[   82.289675] ath10k_pci 0000:01:00.0: Falling back to user helper
[   82.318269] firmware ath10k!QCA99X0!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
[   83.007625] ath10k_pci 0000:01:00.0: qca99x0 hw2.0 target 0x01000000 chip_id 0x003b01ff sub 168c:0002
[   83.007671] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[   83.019219] ath10k_pci 0000:01:00.0: firmware ver 10.4b-ct-9980-fW-13-10af6a005 api 5 features mfp,peer-flow-ctrl,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,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 4a0fa880
[   85.323859] ath10k_pci 0000:01:00.0: failed to fetch board data for bus=pci,vendor=168c,device=0040,subsystem-vendor=168c,subsystem-device=0002 from ath10k/QCA99X0/hw2.0/board-2.bin
[   85.324078] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 7e56fd07
[   88.720583] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16  peers: 48  tid: 96
[   88.720614] ath10k_pci 0000:01:00.0: msdu-desc: 2500  skid: 32
[   88.796636] ath10k_pci 0000:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186  msdu-desc: 2500  sw-crypt: 0 ct-sta: 0'
[   88.797412] ath10k_pci 0000:01:00.0: wmi print 'free: 31080 iram: 23092 sram: 9596'
[   89.009979] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 32 raw 0 hwcrypto 1
[   89.135797] ath: EEPROM regdomain: 0x0
[   89.135811] ath: EEPROM indicates default country code should be used
[   89.135821] ath: doing EEPROM country->regdmn map search
[   89.135840] ath: country maps to regdmn code: 0x3a
[   89.135853] ath: Country alpha2 being used: US
[   89.135863] ath: Regpair used: 0x3a
[   89.143997] ath10k_pci 0001:01:00.0: assign IRQ: got 99
[   89.144020] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x40.
[   89.144581] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[   89.150893] ath10k_pci 0001:01:00.0: enabling bus mastering
[   89.151451] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   89.324173] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/fwcfg-pci-0001:01:00.0.txt failed with error -2
[   89.324222] ath10k_pci 0001:01:00.0: Falling back to user helper
[   89.711191] firmware ath10k!fwcfg-pci-0001:01:00.0.txt: firmware_loading_store: map pages failed
[   89.711420] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0001:01:00.0.bin failed with error -2
[   89.719134] ath10k_pci 0001:01:00.0: Falling back to user helper
[  136.801484] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/ct-firmware-5.bin failed with error -2
[  136.801519] ath10k_pci 0001:01:00.0: Falling back to user helper
[  136.850677] firmware ath10k!QCA99X0!hw2.0!ct-firmware-5.bin: firmware_loading_store: map pages failed
[  136.850936] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/ct-firmware-2.bin failed with error -2
[  136.859030] ath10k_pci 0001:01:00.0: Falling back to user helper
[  136.905054] firmware ath10k!QCA99X0!hw2.0!ct-firmware-2.bin: firmware_loading_store: map pages failed
[  136.905428] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA99X0/hw2.0/firmware-6.bin failed with error -2
[  136.913398] ath10k_pci 0001:01:00.0: Falling back to user helper
[  136.949244] firmware ath10k!QCA99X0!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
[  136.949437] ath10k_pci 0001:01:00.0: qca99x0 hw2.0 target 0x01000000 chip_id 0x003b01ff sub 168c:0002
[  136.957212] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[  136.968763] ath10k_pci 0001:01:00.0: firmware ver 10.4b-ct-9980-fW-13-10af6a005 api 5 features mfp,peer-flow-ctrl,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,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 4a0fa880
[  137.039464] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 1:2 crc32 08fa09f2
[  138.228323] ath10k_pci 0001:01:00.0: 10.4 wmi init: vdevs: 16  peers: 48  tid: 96
[  138.228354] ath10k_pci 0001:01:00.0: msdu-desc: 2500  skid: 32
[  138.306180] ath10k_pci 0001:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186  msdu-desc: 2500  sw-crypt: 0 ct-sta: 0'
[  138.306963] ath10k_pci 0001:01:00.0: wmi print 'free: 31080 iram: 23092 sram: 9596'
[  138.537563] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
[  138.665739] ath: EEPROM regdomain: 0x0
[  138.665753] ath: EEPROM indicates default country code should be used
[  138.665765] ath: doing EEPROM country->regdmn map search
[  138.665782] ath: country maps to regdmn code: 0x3a
[  138.665795] ath: Country alpha2 being used: US
[  138.665804] ath: Regpair used: 0x3a
8

Doesn't it bother you that by not running lastest openwrt version you don't benefit from updates and security patches? I find it strange that nobody really seems to care that apparently multiple users experience firmware instability duo to ath10k-ct not performing as it should, causing the qca9*** platform to be unreliable from 20.02 and onwards?

9

19.07.8 is still fully supported.

So, no...not if I'm running 19.07.8 or newer.

I switched to ct-smallbuffers on 21.02.1 and it's working well.

ath10k is known to be problematic.

Whenever you have some free time, watch this video...

3 Likes
10

It doesn't bother me enough, to upgrade, in this case I prefer stability before newest security (patches).

11

Thanks for the video link. I've watched it and, to be honest, was pretty shocked . I was aware that opensource and wireless drivers are problematic (duo to lack of sourcecode and binary blobs), but wasn't aware that there are so many issues.

From what i can conclude from the presentation felix gave: ath9k is pretty good but old, ath10k is a big mess duo to binary blobs: closed source firmware and lots of proprietary hardware ofloading. Now candelatech has access to the ath10k related firmware sources under an nda, but unfortunately the ath10k-ct drivers is less stable for me then the ath10k standard one.

Spinning my thoughts around what is being told in the presentation, i'm wondering if it at all is logical to persue the c2600/ath10k road. Felix was very positive about mediatek and their openness and willingness to participatie in opensource firmware. Because, as far is a can see, there's not much more to choose from: broadcom on alternative firmware is only usable with ddwrt (because of their nda with broadcom), marvell and intel/lantiq isn't very good either (in participating in the opensource firmware development) , that leaves us almost only with mediatek.

The problem with mediatek devices is, as far as i can see, there arent much or even any comparable mediatek devices that can do the same as ipq8064 / ath10k. There are the rt3200/e8450, but those arent available in my part of the world (western europe).

Leaves me wondering, when 19.07.8 is stable, and 21.02.1 isn't, does that mean that 19.07.8 uses ath10k driver and 21.02.1 the candelatech ath10k-ct one?

This atk10k-ct smallbuffers you speak about, is this a even more modified version of the candelatech ath10k-ct driver? And if so, how can i use it? Can i switch to this specific driver with an existing c2600 image or do i have to compile an entire new image from scratch?

I'm sorry for the 1000 questions. The video from Felix really made me retink a lot of wireless issues, and wasnt very optimistic (especially looking forward to ax-wireless / wifi-6).

As far as i'm concerned, the presentation felix gave really should be mandatory for anyone considering using alternative firmware with wireless functionality in general.

12

To go from CT to CT-Smallbuffers -

opkg remove kmod-ath10k-ct
opkg update && opkg install kmod-ath10k-ct-smallbuffers

Quite a few MediaTek devices supported in OpenWRT...

MediaTek Devices

Once the Belkin RT3200 is include in the release, it's my number one candidate to replace my Archer C7 v2.

2 Likes
13

I’m running 4 access points that all use Ath10k with no issues. I have switched from the -ct firmware to the non-ct. I’m running the master branch from a few days ago and the non-ct drivers were updated on Dec 16, 2021.

So even if it’s closed source, it still gets updated and it’s been working really well for me for a year and a half now with my current setup.

14

Thanks; i'm having trouble finding out in what release the ath10 driver was replaced bij ath10-ct. If this happened indeed between 19.7.8 and 20.02.1 this would explain why 20.02.1 is so unstable. I can't find in the the changelogs for these releases.

I've looked at the available mediatek devices. Strangely enough not a lot of them are available in western europe. They're also not very cheap, where the rt3200 costs about €120,- and the ubiquiti unifi 6 lr around €200,- . A major drawback for me on the e8450/rt3200 is that it's not possible to mount them to the wall at their side. They can only be positioned on their bottom stand.

@chadneufeld I have the same experience with 19.7.8, runs rock solid and gives me no issues. It seems i have to find out how to switch to ath10k (non -ct) on 21.0.2.1, is this the same procedure as @anon89577378 describes?

If i'm looking at the multiple threads about the c2600 router on the openwrt forum, it seems that a general consensus is reached. One that describes lots of users having issues with the candelatech firmware. And those users that run the non-ct firmware/drivers and have no issues. I'm wondering if it would be better to return to ath10k (non-ct) for the c2600 as a default driver/firmware, especially when there are so many users having issues with the candelatech firmware/driver.

And since candelatech works under and nda, it seems where not really aware whats happening under the hood, what they've changed, There is no changelog on their website and they aren't allowed to publicise what they have changed in the qualcomm firmware. That's a black box being modified into another black box.... Please correct me if i'm wrong, just trying to make sense on all of this.

15

For your device -

opkg remove ath10k-firmware-qca99x0-ct kmod-ath10k-ct
opkg update && opkg install ath10k-firmware-qca99x0 kmod-ath10k

If you installed the ct-smallbuffers, change the "remove" command to this...

opkg remove ath10k-firmware-qca99x0-ct kmod-ath10k-ct-smallbuffers
3 Likes
16

Thank you! Where i at first had given up on c2600 with openwrt, i (we) now have a new way of making it stable and working again for the new release. Will these alterations stay in place when updating, or do i have to manually replace to driver each time a version update has been applied?

17

The "default" (CT) drivers will be installed.

18

So it has been around a week since i've updated to 21.02.1 and replaced the ath10k-ct driver with the generic ath10k one. And after a week having zero issues i can only come to the conclusion: while ath10k is very stable, ath10k-ct has serieus issues. This was also noticed by other forum members.

Which brings me to the question: how can we make ipq8064/qca9880 more usable in upcoming releases of openwrt. Would it be an idea, since so many experience issues with ath10k-ct, to switch back to ath10k. At least until ath10k-ct has it's issues resolved? I'm no expert, but it seems to me this would help a lot of openwrt users and saves them from opening forum threads and reporting unstable wifi for their devices.

Or maybe there's an other, better way to push forward?

At least i'm glad i'm again able to run the latest openwrt release on my c2600 . When things went bad after initial 21.02 update, i had to revert back to 19.7.8 , simply because the c2600 wasnt usable anymore with wireless constant dropping (especially on 2.4ghz).

1 Like
19

Glad it's working for you.

My experience has been different.

On my Archer C7 v2, I've used the following with no issues -

19.07.8 - ath10k drivers

21.02.1 - ath10k-ct-smallbuffers drivers

Since ath10k is not OpenWRT-specific, not much can be done to improve it in future releases.

You could also forward any feedback on the CT drivers directly to Candela Technologies..

https://www.candelatech.com/support.php

20

I've looked in to the c7 v2. Seems that a big difference between it and the c2600 is that the c7 v2 uses qca9558 for 2.4ghz and qca9880 for 5ghz (3x3), while the c2600 uses qca9980 for both 2.4ghz and 5ghz. As you mentioned you didnt experience problems using ath10k-ct-smallbuffers, it seems that driver doesnt have any issues with qca9558. The main source of the problems i experience with ath10k-ct, is 2.4ghz on qca9980 dropping. So these two devices can't be compared since they use different silicon for their 2.4ghz portion.

"Since ath10k is not OpenWRT-specific, not much can be done to improve it in future releases."
This i don't understand. Has a driver to be maintained by openwrt for it to receive future improvements?

Just searching for ath10k driver development leads me to the linux wireless page. It seems the driver still is being maintained and developed. It also seems to be possible to report bugs or submit contributions. Since i'm not familiar with linux development, i'm not sure where the difference sits for a driver to be developed by the linux wireless guys or someone from the openwrt crew? Actually, i wasn't even aware that ath10k-ct is openwrt specific.

1 Like