Undoing TP-Link Archer C7 v2 overclock remotely

I am still in the Philippines, but my mother still lives in Russia. She still has a TP-Link Archer C7 v2 with OpenWrt 21.02.1, r16325-88151b8303 installed. I have remote access to the unit, but returning to Russia is completely out of the question for obvious safety reasons.

The problem is that this unit is still in an overclocked state (1 GHz), and I suspect that it might be the cause of the 2.4 GHz WiFi instability (5 GHz WiFi is unused) that manifests itself every two weeks or so. Having said that, with all the reboots, it has worked in that location for 1.5 years already. Still, I want to undo the overclock remotely and update the firmware to a supported version.

Let's deal with undoing the overclock first. As this is a super-risky and undocumented operation (the documented procedure is to use the web interface of Breed, but I can't explain this to a non-technical person), I would like someone to comment on the proposed preparations and the procedure.

I have another TP-Link Archer C7 v2, and I tried to overclock it using the same version of Breed (Build date 2020-10-09 [git-676bfd4]). So I have something to practice on.

I have already compared the bytes on /dev/mtd0ro of my mother's router and in the freshly downloaded Breed file:

$ sha256sum breed-qca9558-ar8327n.bin
eb53e06de0072bbaf42c7ec4aed1c0dfe9e7d6ec95ffac1736759365cc684706  breed-qca9558-ar8327n.bin
$ diff -u breed-qca9558-ar8327n.bin.xxd Archer.mtd0.bin.xxd | grep -v 'ffff ffff ffff ffff ffff ffff ffff ffff'
--- breed-qca9558-ar8327n.bin.xxd	2023-10-29 18:17:31.195550193 +0800
+++ Archer.mtd0.bin.xxd	2023-10-29 18:17:31.177550195 +0800
@@ -1,7 +1,7 @@
 00000000: 1000 00ff 0000 0000 0000 0000 0000 0000  ................
 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+00000020: 504c 4c43 0000 0019 0000 0001 0000 0010  PLLC............
+00000030: 0000 0001 0001 0000 0000 0000 0000 0000  ................
 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
@@ -5937,4 +5937,2256 @@
 00017300: 1f0f def6 caf4 fa0e 448f 4842 9382 4655  ........D.HB..FU
 00017310: 9a22 8e09 d615 576f 0f90 d547 5d16 bd88  ."....Wo...G]...
 00017320: 93cc b931 b39e ec13 473e afd1 ff08 e309  ...1....G>......
-00017330: 7523 cc85 ad4d fa78 00                   u#...M.x.
+00017330: 7523 cc85 ad4d fa78 00ff ffff ffff ffff  u#...M.x........
+0001fc00: e8de 27f6 28d6 ffff ffff ffff ffff ffff  ..'.(...........
+0001fe00: 3132 3334 3536 3730 ffff ffff ffff ffff  12345670........

So, it seems like the bytes that differ have the following roles:

  • bytes with offsets 00000020-00000035 contain PLL settings (i.e. are related to the overclock - note that they would be blank immediately after flashing Breed)
  • the diff line mentioning 00017330 is there because that's the EOF of the original boot loader file
  • bytes at 0001fc00-0001fc05 contain the MAC address of eth1
  • the MAC address of wlan0 is not stored in the mtd0 partition, but somewhere else (confirmed on my router that changing it does not alter the /dev/mtd0ro contents and that the change is not picked up by OpenWrt anyway)
  • bytes at 0001fe00-0001fe07 contain the WPS PIN (not used by OpenWrt).

There are no other differences.

Based on that, I propose the following procedure: erase the bytes that contain the PLL settings and reboot.

I have already tried the following commands on my local device, they have worked, and I didn't need physical access:

dmesg | grep clock
cd /tmp
dd if=/dev/mtd0ro of=mtd0.bin
dd if=/dev/zero of=mtd0.bin bs=1 count=32 seek=32 conv=notrunc
insmod mtd-rw i_want_a_brick=1
mtd unlock u-boot
mtd -r write mtd0.bin u-boot

After the local router rebooted, the overclock (as tested with dmesg | grep clock) was gone. However, I am still hesitant to run these commands on a remote device that I have no way to unbrick if anything goes wrong.

Is there anything that I have missed?

Honestly doesnt sound like that overclock is the problem. I’d try to

  1. flash 23.05.0
  2. use ath10k-ct-smallbuffers or ath10k-smallbuffers drivers
  3. non ct firmware

Even if the overclock is not a problem, I would like to keep replies like "flash 23.05.0" out of this topic. I will do this eventually, but it also needs a procedure to make sure that I don't lose access and nothing breaks. I will create a separate topic for this when I get to planning the upgrade.

Edit: here is the new topic for the upgrade procedure.

Upgrade to 23.05 should be straigthforward compared to a possible brick so that’s why I mentioned it. But I get it.

Every time i’ve had wifi trouble in the past, it was always the ct firmware that was the culprit. But I would make an image with this included instead of doing up through opkg.

On your unit set Breed back to not overclock then look at the bytes again. I would pull an image of Breed running regular clock, patch in the MAC for the other router, and flash the whole bootloader to your test unit. If that works then you should be able to flash that same file the remote router.

WiFi MACs are in the ART partition this should not be affected.

1 Like

I have looked at the bytes. If I just flash Breed and never visit its web interface, they are all zeros. In other words, Breed does not overwrite these bytes unless asked, and does not overwrite them on the first boot. If I visit the UI and press "save" without changing anything, the bytes are:

00000020: 504c 4c43 0000 0012 0000 0001 0000 000f  PLLC............
00000030: 0000 0001 0101 0000 0000 0000 0000 0000  ................

In both cases, the router runs at 720 MHz, i.e. is not overclocked.

Flashing the same image to both routers (i.e. doing all the commands up to and including dd remotely, then downloading the result, flashing locally, and, if it works, flashing remotely) would definitely be an improvement to my original procedure. Thanks for that!

your 2.4G instability may be related with 'ldpc' setting in /etc/config/wireless.

The procedure as described in the original post has worked.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.