[Consistent Router Crash] Bug in Existing Firmware of Archer C7 (Patch Released)

For Developers
1

There is a nasty bug in the Archer C7 firmware. I got a new Dell XPS 9630, with Killer Wifi 1535 network card. If I initiate a local transfer over the network (i.e. stress the wifi out), the Archer C7 will crash within a min or so. Everyone with a Killer 1535 and Archer C7 expirence this. This is not a LEDE bug, but an QCA chipset bug. I've tested this on LEDE (Sept), LEDE (Jan), and Stock TP-LINK (Latest). All 3 firmwares would crash the router within a minute of stressing the 5GHz network using the Killer Wifi 1535. All other network cards are fine, just the Killer Wifi will crash the Archer C7. Once crashed, a router reboot is nessasary.

This is a pretty serious bug, considering anyone with a new Dell (or anyone with a qualcomm atheros qca61x4a/QCA6174 chipset) connects to the Archer C7 will crash the router. It seems like Killer NIC is the main culprit, but TP-Link shouldn't crash when a naughty client connects to it, so both are to blame.

The discussion is described in more detail here:
http://forum.tp-link.com/showthread.php?94180-Archer-C7-router-crashed-by-Dell-laptop-with-Killer-adapter/

Anyway, QCA has released a patch to fix this issue, and gave it to TP-LINK. TP-LINK made several "beta" firmwares with the patch applied to see if it fixes the issue. Several people have reported that it has fixed it. It would be nice if we could get this patch pushed to LEDE/OpenWRT. Currently we just have access to the BETA Firmwares, but not the physical patch. I do not know if we would ask TP-LINK for it, or QCA (who gave it to them first). Or if it'll just appear into the ath10k-firmware git eventually? Or if we can extract it from the beta firmware outselves...

I've used the latest LEDE with (QCA988X 10.2.4-1.0-00016), and the problem still exists in this version. I do not know if the patch is even with this firmware, or somewhere else?

I've included some of the more relevant posts from the topic above and quoted them below. Maybe if someone knows how to contact QCA or maybe kvalo to see if this Archer C7 patch to fix the incompatibility issues with qca61x4a chipset will eventually get pushed to the public firmwares?

I've been very impressed with TPLINK on how responsive they have been to their customers about this problem, and how quickly they pushed a beta firmware with the patch for people to test. Now if we could get it pushed to LEDE so our LEDE Archer C7 won't crash if you have a friend come over and connect with a qca61x4a adapter in it.

[QUOTE=TPLINK_SUPPORT]Hi All,

Solutions for different versions (download link), hope they will help you!

Archer C7 V2
US: http://static.tp-link.com/resources/software/ArcherC7v2_en_us_3_15_1_up(160511).zip
CA: http://static.tp-link.com/ArcherC7v2_fr_ca_3_15_1_up_boot(170118).zip
EU: http://static.tp-link.com/ArcherC7v2_en_eu_up.zip

Archer C7 V3
US: http://static.tp-link.com/ArcherC7v3_en_up.zip

Archer D7 V1
EU: http://static.tp-link.com/resources/software/Archer_D7_Beta_V1_160708.zip[/QUOTE]

[QUOTE=TPLINK_SUPPORT]Hi deboralbasso,
The Killer adapter is exactly the root cause. It's a compatibility issue between Killer series adapter & QCA chipset of C7.
We did report this issue to QCA before and got a patch from them.
And we also made a beta firmware with the patch. Please download and install it on your Archer C7 V2 from the link that Doom shares:
((SEE PREVIOUS POST))
It should fix the issue.

Hi KK4NAG,
Thank you for your feedback.
Actualy Archer D7 & Archer C7 adopts the same wireless chipset from QCA. So maybe this issue exists with D7 & Killer.
However, we never receive any similar feedback on D7. Could you reply me the hardware & firmware versions of your D7? So that we can try to get a beta firmware to you.
If any other problem, please don't hesitate to post and share here.[/QUOTE]

[QUOTE=TPLINK_SUPPORT]You can try to install the beta firmware as well.
The beta not only solves the compatibility issue with Killer adapters but also fixes some other wireless problems.
If it doesn't make sense, it's recommended to create a ticket to TP-Link's support team for a follow up.[/QUOTE]

[QUOTE=TPLINK_SUPPORT]The beta firmware is a US version which means that customers in USA could upgrade it.

Actualy this beta has the same firmware version 3.15.1 with the official 160719. However, the patch in the beta wasn't added in 160719 as it's given by QCA. In consideration of stability (maybe the patch would have other compatibility problems with other wifi adapters, just not sure), we only add the patch in the beta to help customers that suffering the router crash issue.
However, we will work on this compatibility issue with Dell computers and once get a perfect solution, will release an official firmware to replace the beta.[/QUOTE]

2

Your description is a bit vague to me.

First you wrote "Patch Released" but then I found this:[quote="codster314, post:1, topic:1129"]Currently we just have access to the BETA Firmwares, but not the physical patch.[/quote]

So is this patch available or not?!

Are you able to specify if this is problem with Linux kernel athk10k driver (which could shared the same bug as whatever TP-LINK uses) or wireless chipset firmware? Did anyone report this problem upstream (linux-wireless mailing list)? If not, please do so.

3

Sry, yea I just mean that TPLINK released beta firmware with the patch applied to fix this issue. And it apparently fixes the issue So the patch exists, but not available outside the TPLINK Beta Drivers.

QCA made the patch and gave it to TPLINK.

The patch will have to be given from TPLINK or QCA or extracted manually from the TPLINK Beta Firmware (above).

I'm unsure if it's the chipset firmware, or the kmod-ath10k driver. I suspect it's the QCA firmware though.

It may just appear eventually in kvalo's QCA firmware github eventually.

4

[quote="codster314, post:3, topic:1129"]The patch will have to be given from TPLINK or QCA or extracted manually from the TPLINK Beta Firmware (above).[/quote]You usually patch sources and TP-LINK image contains binary code only.

[quote="codster314, post:3, topic:1129"]It may just appear eventually in kvalo's QCA firmware github eventually.[/quote]I think we know nothing of QCA internal teams & code maintenance. It's a poor idea to just wait & see what happens. Please report this issue on linux-wireless mailing list.

5

hehe, the chipset firmware files are usually binary blobs and not source code. For example if you wanted to update the ath10k-firmware/QCA988X (Archer C7 firmware), then you would get the binary blob firmware from:

kvalo/ath10k-firmware: github.com/kvalo/ath10k-firmware/tree/master/QCA988X/hw2.0/10.2.4-1.0

Download the binary files: firmware-5.bin 10.2.4-1.0-00016, and board.bin, and move them into the appropriate folder. There is no source available in his repo to even download. Everything is just binary blobs. LEDE just downloads the binary blob from this repo. It doesn't compile it from source. So any patches to these binary blobs would be difficult for LEDE anyway.

If it was a firmware update patch, QCA probably just gave TP-LINK an updated firmware binary file. That's why I said (if it's a firmware update at least) we can probably extract the firmware binary from the Archer C7 (through the serial link or TFTP or extract from the file), copy the firmware, and move it into the LEDE. Then we can test the extracted qca chipset firmware in a LEDE distribution and see if the problem is fixed.

The Archer C7 is my main router, so I haven't had time to do so. But it's something I'll do and test when I have time and I can take my internet down for a few hours. Of course if it was some other patch QCA supplied it'll be a bit more difficult to find. We could compare the beta firmware to the latest stable. and see what changed or ask for the patch directly from someone.

6

I'm well aware of what a firmware is.

[quote="codster314, post:5, topic:1129"]That's why I said (...) we can probably extract the firmware binary from the Archer C7[/quote]No, you said:

[quote="codster314, post:3, topic:1129"]The patch will have to be given (...) or extracted manually from the TPLINK Beta Firmware (above).[/quote]That didn't make much sense (you can extract binary, not a patch), that's why I pointed it out.

7

Any solutions to this issue yet? Seems a bug is open on openwrt for this issue since 22 months go
https://dev.openwrt.org/ticket/19627

8

Not much. Killer has released new drivers which helps the client side to not "disconnect" wifi under load. However it will still crash the Archer C7 (and other similar chipset routers).

TP-LINK has still released only BETA firmware, which includes an unavailable patch from QCA which people say does fix the problem. Unsure on how or who we can get this patch from (TPLINK/QCA/Others?).

The latest firmware from kvalo (firmware-5.bin_10.2.4-1.0-00016) doesn't fix the problem.

I've extracted the filesytem of TP-LINK's beta firmware (using ddwrt's extract_firmware.sh tools). But couldn't figure out where the qca patch/firmware file was. Wasn't any use.

9

Status: waiting for a hero who will write problem description and send it to linux-wireless ML instead of just complaining here.

10

Step 1)Flash the old tp-link factory firmware
Step 2)Checksum the files
Step 3)Flash the fix firmware
Step 4)Diff the files
Determine if it is the art partition or qca binary blob
Replace the files

11

Hey @gwlim, yea I tried those steps. I didn't flash the firmware, I just extracted it using the "ddwrt's extract_firmware.sh tools", which showed the squashfs filesystem.

But when I diff'ed the files, too much was changed between the versions. The problem with the BETA fixed drivers is that they are based on a firmware which hasn't been released. So lots of differences. Also, I couldn't find the QCA binary blob in the "extracted firmware". So i didn't get far.

This is with the extraction tool. I didn't try flashing both to the hardware first. With the official firmware, how would we access the filesystem? TELNET?