TP-Link Archer C7 AC1750

The TP-Link Archer C7 AC1750 is a wireless router with both 2.4 GHz and 5 GHz radios. It has five 1 gigabit/second Ethernet ports, and a moderately fast processor. Available since 201x.

Hardware versions v1, v2 and v3 use 3 external antennas for 5 GHz and 3 internal antennas for 2.4 GHz. Versions v4 and v5 use only 3 external dual-band antennas, for 2.4 GHz and 5 GHz. In these more recent versions, the 5 GHz chipset is integrated with the mainboard.

The Dutch “Ziggo Wifibooster C7” is a rebranded v2, see instructions below on how to create a compatible firmware.

OpenWrt Factory Firmware: Use this file the first time you flash OpenWrt onto the router as it came from the “factory.”
OpenWrt Sysupgrade Firmware: Use this file to upgrade an OpenWrt “system” to a newer OpenWrt version.
OEM Stock Firmware: Use this file to restore the router to the “stock” firmware as it shipped from the manufacturer.

→ Install OpenWrt

For Archer C7 v1.1, v2, v2.1, v4, and v5 (fw1.0.11, fw1.2.0), installing OpenWrt is confirmed to work by simply uploading the OpenWrt firmware in the stock OEM's firmware-upgrade page. Please note, however, that this page will refuse to install firmware uploaded with a long filename. To bypass this limitation, download the relevant factory-flash BIN file and then rename the file to firmware.bin before uploading.

Archer C7 v2 may require region-specific firmware. For example, OpenWrt 22.03.4 exists in non-region-specific version (factory.bin), EU version (factory-eu.bin), and U.S. version (factory-us.bin). When installing via Web-based interface, the device will refuse to install the incorrect version and display a generic error message along the lines of “there's something wrong with this firmware, but I can't tell you what”. The solution is to use the region-specific firmware matching the region-specific hardware. Renaming the firmware image to firmware.bin before upload (see previous paragraph) is still a good idea.

For older stock firmware version for the Archer C7 v5, installing OpenWrt is only possible through TFTP server, (v18.06.1 confirmed) Make sure to upgrade the stock firmware first if you want to use the manual firmware upload feature which can be easier than setting up a TFTP server.

For Archer C7 v5 OEM fw 1.0.11 Build 20190726 the router refuse install OpenWrt v21.02 from OEM's firmware-upgrade page or via TFTP, but it's possible to install OpenWrt v19.07.2 using the OEM UI, and from that do the upgrade to v21.02 using LuCI.

For Archer C7 v5 OEM fw 1.2.0 and fw 1.1.4 the router accepted the openwrt-21.02.3 firmware image via upgrade page without issues.

As stated above, “Ziggo Wifibooster C7” is a rebranded v2. You can find instructions on how to create a compatible firmware for flashing below.

1. download stock TP-Link firmware from https://www.tp-link.com/nl/support/download/archer-c7/v2/#Firmware
2. with a hex editor replace 0x00000000 with 0x4E4C0001 at offset 0x4B
3. download and build mktplinkfw (see code block below)
4. run ./mktplinkfw -i firmware.bin
5. the MD5 checksum will be displayed as wrong; make sure your hardware ID is 0xc7000002 otherwise it means you have downloaded the wrong firmware
6. open again the firmware.bin file with your hex editor and replace the bytes from 0x4C to 0x5B with the expected checksum as shown by mktplinkfw
7. verify that checksum is now correct with mktplinkfw
8. your firmware is now ready to be uploaded via web UI

Original instructions in Dutch can be found here: described here

Use the general instructions for entering recovery mode (quick Reset button early in the boot process). Then connect an Ethernet to LAN1, configure your computer for a static IP (say, 192.168.1.100), then ssh root@192.168.1.1. Enter firstboot, then enter reboot. The Archer C7 will then start in factory defaults.

It is possible to install OpenWrt over TFTP on this model. The same method also works for restoring back to the stock firmware.

→ generic.flashing.tftp

Note an annoying firmware bug: For at least Archer C7 v2, there is a bug in the bootloader that causes it to erase only 124 sectors of the flash (slightly less than 8M) before writing (rather than the expected 250-ish for 16M of flash). Therefore, this method will not write images completely correctly, but images that find everything they need within those 124 sectors will correctly erase the rest and proceed. Other, larger images will appear to flash correctly and then will boot to see corrupted contents in the upper 8M of flash, leading to all kinds of excitement (such as squashfs being unable to find its indices). That said, the pre-built OpenWRT images (as of 22.03.2) have small enough kernels and squashfs roots that they fit completely within the 124 sector window available; larger images can then be landed using sysupgrade, which knows to erase the second half of flash, too.

Connect one of the yellow (switch) LAN ports to a machine running a TFTP-server. Configure the server machine with IP 192.168.0.66/24 (subnetmask 255.255.255.0, 'router' option can be empty) [1]. The router will run as a TFTP client at 192.168.0.86.

Obtain a stock firmware or a 'factory' OpenWrt image. Store the firmware on the TFTP server as ArcherC7v2_tp_recovery.bin. Replace the v2 with your hardware version number if you don't have a v2.

To start the TFTP recovery process on the router, press and hold the WPS/Reset Button and then power up the router. Keep the WPS/Reset button pressed until the WPS LED turns on (it's the LED with two arrows pointing in different directions).

Note: For Archer C7 v2, there is a combined WPS/Reset button. For Archer C7 v4 and v5, you must use the dedicated “Reset” button near the power button.

If everything went right, you should see a read request in your TFTP server. The flash operation takes about 3 to 5 minutes.

Archer c7 v5 back to the original software I also had this problem and I can upload any software to C7v5. I just tested today, I know a lot of users have this problem. It has always been tftp over time that it has timed out. It is known that in the network card we set the ip address: 192.168.0.66 mask 255.255.255.0

Having TFTP Problem with TP-Link Archer c7 v5 (EU) I have explained in DETAIL under section If flashing fails..

Now use this tool: tftpd32

Everything is almost set, you just need to unpack the access path (i.e. in tftp you press BROWSE and you choose in the main directory i.e. (tftpd32) is the original C7v5 soft tplink, while in other directories there are softs (ddwrt, gargoyle, openwrt) that with an unoriginal software you can upload a second soft, but using a browser. For example, I uploaded the soft ddwrt from the directory (ddwrt factory) then you need to upload the second from the same directory through the soft browser (tplink_archer-c7-v5). Uploading software: once you have the network card set up. fire up tftpd32 select the soft you want connect the router to your computer using a lan (router turned off from the power button at the back) now turn on the button on the back and simultaneously hold the reset for about 7 seconds. it will start loading soft into the router, wait about 10-15 minutes for the lights to light up.

[1] The TFTP server may need to be at 192.168.1.66 - see https://forum.openwrt.org/t/tp-link-archer-c7-v1-v2-jtag-u-boot-recovery-using-st-link-v2-usb-adapter-clone-known-as-baite/39582/43

• Tested with (K)ubuntu 22.04 and a TP-Link Archer C7 AC1750 v5 (EU).

First, use a network cable to connect your computer to the first LAN port of the router. Open a terminal and connect to the router via SSH.

Make a folder for the TFTP server:

sudo mkdir /srv/tftp/

Move the downloaded OEM firmware file into the TFTP folder. Make sure the hardware version of your TP-Link router is exactly in the filename. In the example command below, a TP-Link Archer C7 AC1750 version 5 is used. Replace “v5” in the filename with your hardware version.

sudo mv ArcherC7v5_tp_recovery.bin /srv/tftp/ArcherC7v5_tp_recovery.bin

Now install the TFTP server, here we use tftpd-hpa since it is well used and documented.

sudo apt install tftpd-hpa

Change the permissions of the folder and the firmware file:

sudo chown tftp:tftp /srv/tftp /srv/tftp/ArcherC7v5_tp_recovery.bin

Configure the TFTP server:

sudo nano /etc/default/tftpd-hpa

/etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="192.168.0.66:69"
TFTP_OPTIONS="--secure"

Use netplan to configure the interface temporarily.

sudo nano /etc/netplan/01-netcfg.yaml

/etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      addresses:
        - 192.168.0.66/24
      routes:
        - to: default
          via: 192.168.0.1

Now, apply the netplan and restart the tftpd-hpa service.

sudo netplan apply
sudo systemctl restart tftpd-hpa.service  

Allow TFTP in the firewall.

sudo ufw allow tftp

Check your configuration, you should see the TFTP daemon listening on port 69.

sudo netstat -ulpn

Now, power down the router. Hold the reset button (on some hardware versions, it is combined with the WPS button) and power on the router. Keep pressing the button until the WPS LED lights up on the router case. The LED is usually depicted as two (circular) arrows pointing at each other. The firmware installation process may take several minutes to complete.

Lastly, clean up the now unneeded files and configuration:

sudo ufw deny tftp
sudo apt purge tftpd-hpa
sudo rm /srv/tftp/ArcherC7v5_tp_recovery.bin
sudo rm /etc/netplan/01-netcfg.yaml
sudo rm /etc/default/tftpd-hpa

Some versions of the Archer C7v5 (US) firmware (others might also be affected) do not reply to ARP properly, and the tftp fails because of that.

To see if that's what's happening, have “tcpdump -i <your ethernet interface> -nv -e” running and try the recovery procedure. If there are no replies to your computer asking for “who-has 192.168.0.86” (or 192.168.1.86), that's your problem.

To work around it, look at the source MAC for the who-has 192.168.0.66 message the router sent (and your computer replied), and add it manually to the arp table: arp -s 192.168.0.86 _router's bootloader MAC address_.

The following flash partition layouts were found on this TP-Link router by inspecting /proc/mtd and dmesg:

TP-Link Archer C7 v1.1

TP-Link Archer C7 AC1750 v2 and v2.1:

TP-Link Archer C7 AC1750 v4 on OpenWrt 19.07.6:

TP-Link Archer C7 AC1750 v5 on OpenWrt 19.07.6:

Looks similar to the v2:

... but note that what is marked 'TX' in this image is actually the RX of the routers (so should be connected to the TX of the dongle) and vice-versa for RX.

To enter the u-boot prompt, enter 'tpl' when the message 'Autobooting in 1 seconds' is displayed.

Use 115200 baud 8N1.

RX pin not connected to connector. Before soldering connector, connect RX wire to R27, like on the photo:

ver: 5.0

Archer C7 v1, v2 and v3 should all be possible to recover from damaged u-boot via JTAG, for v1 JTAG recovery is confirmed.

TP-Link Archer C7 v1/v2 JTAG u-boot recovery using ST-Link v2 USB adapter clone known as Baite

Download Versaloon firmware (md5 ed4f8fee72e27a4297248d572c784583) for the adapter and flash it to the device following this procedure:

Get an USB-UART adapter, in this case CP2102 was used and connect it to Baite as shown in the photo.

Plug in the USB-UART adapter to your PC and flash Versaloon firmware by issuing these commands:

Important: Do not plug in Baite adapter to USB port at this point!

stm32flash -k /dev/ttyUSB0
stm32flash -u /dev/ttyUSB0
stm32flash -o /dev/ttyUSB0
stm32flash -w Versaloon-STM32F103C8_Baite.bin -v /dev/ttyUSB0

Note: this was done on ubuntu 16.04.6, other OS may recognize USB-UART different than ttyUSB0, -k and -u parameters disable flash read/write protection, -o erases flash and -w writes firmware to it

Disconnect the USB-UART adapter from Baite and verify that the new firmware is running properly by plugging in Baite to your PC. lsusb should display 0483:a038 STMicroelectronics ID.

Disconnect Baite from PC and proceed with JTAG connection to the router. You need to connect 5 pins to the board: TCK, TMS, TDI, TDO and GND.

Wiring schematics:

Next plug in Baite to your PC, and short CS pin of the SPI flash chip on router to one of the router's GND pins. Power on router and remove the object used to short CS pin after few seconds (when ethernet LEDs go off)

Now run the actual debug program, OpenOCD:

openocd -f interface/vsllink.cfg -f target/ath79.cfg

It should display the following content:

Open On-Chip Debugger 0.10.0+dev-00916-g42cee46 (2019-06-20-15:01)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
jtag
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Versaloon(0x22)by Simon(compiled on Jun 21 2019)
Info : USB_TO_XXX abilities: 0x00000008:0x00000083:0xC0000007
Info : clock speed 100 kHz
Info : JTAG tap: ath79.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Info : Listening on port 3333 for gdb connections

Now open telnet session in another terminal and issue reset command to verifiy things are working:

telnet 127.0.0.1 4444
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger
> reset
JTAG tap: ath79.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)

Issue halt command to enter debug mode:

> halt
MIPS32 with MIPS16 support implemented
target halted in MIPS32 mode due to debug-request, pc: 0xbfc005ec

Issue reset-init command to disable flash remap:

> reset init
JTAG tap: ath79.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
target halted in MIPS32 mode due to debug-request, pc: 0xbfc005ec

Try to detect SPI flash chip:

> flash probe 0
Found flash device 'win w25q64fv/jv' (ID 0x001740ef)
flash 'ath79' found at 0xbf000000

Show more info about SPI flash chip:

> flash info 0
#0 : ath79 at 0xbf000000, size 0x00800000, buswidth 0, chipwidth 0
	#  0: 0x00000000 (0x10000 64kB) protected
	#  1: 0x00010000 (0x10000 64kB) protected
	#  2: 0x00020000 (0x10000 64kB) protected
	#  3: 0x00030000 (0x10000 64kB) protected
	#  4: 0x00040000 (0x10000 64kB) protected
	#  5: 0x00050000 (0x10000 64kB) protected
	#  6: 0x00060000 (0x10000 64kB) protected
	#  7: 0x00070000 (0x10000 64kB) protected
	#  8: 0x00080000 (0x10000 64kB) protected
	#  9: 0x00090000 (0x10000 64kB) protected
	# 10: 0x000a0000 (0x10000 64kB) protected
	# 11: 0x000b0000 (0x10000 64kB) protected
	# 12: 0x000c0000 (0x10000 64kB) protected
	# 13: 0x000d0000 (0x10000 64kB) protected
	# 14: 0x000e0000 (0x10000 64kB) protected
	# 15: 0x000f0000 (0x10000 64kB) protected
	# 16: 0x00100000 (0x10000 64kB) protected
	# 17: 0x00110000 (0x10000 64kB) protected
	# 18: 0x00120000 (0x10000 64kB) protected
	# 19: 0x00130000 (0x10000 64kB) protected
	# 20: 0x00140000 (0x10000 64kB) protected
	# 21: 0x00150000 (0x10000 64kB) protected
	# 22: 0x00160000 (0x10000 64kB) protected
	# 23: 0x00170000 (0x10000 64kB) protected
	# 24: 0x00180000 (0x10000 64kB) protected
	# 25: 0x00190000 (0x10000 64kB) protected
	# 26: 0x001a0000 (0x10000 64kB) protected
	# 27: 0x001b0000 (0x10000 64kB) protected
	# 28: 0x001c0000 (0x10000 64kB) protected
	# 29: 0x001d0000 (0x10000 64kB) protected
	# 30: 0x001e0000 (0x10000 64kB) protected
	# 31: 0x001f0000 (0x10000 64kB) protected
	# 32: 0x00200000 (0x10000 64kB) protected
	# 33: 0x00210000 (0x10000 64kB) protected
	# 34: 0x00220000 (0x10000 64kB) protected
	# 35: 0x00230000 (0x10000 64kB) protected
	# 36: 0x00240000 (0x10000 64kB) protected
	# 37: 0x00250000 (0x10000 64kB) protected
	# 38: 0x00260000 (0x10000 64kB) protected
	# 39: 0x00270000 (0x10000 64kB) protected
	# 40: 0x00280000 (0x10000 64kB) protected
	# 41: 0x00290000 (0x10000 64kB) protected
	# 42: 0x002a0000 (0x10000 64kB) protected
	# 43: 0x002b0000 (0x10000 64kB) protected
	# 44: 0x002c0000 (0x10000 64kB) protected
	# 45: 0x002d0000 (0x10000 64kB) protected
	# 46: 0x002e0000 (0x10000 64kB) protected
	# 47: 0x002f0000 (0x10000 64kB) protected
	# 48: 0x00300000 (0x10000 64kB) protected
	# 49: 0x00310000 (0x10000 64kB) protected
	# 50: 0x00320000 (0x10000 64kB) protected
	# 51: 0x00330000 (0x10000 64kB) protected
	# 52: 0x00340000 (0x10000 64kB) protected
	# 53: 0x00350000 (0x10000 64kB) protected
	# 54: 0x00360000 (0x10000 64kB) protected
	# 55: 0x00370000 (0x10000 64kB) protected
	# 56: 0x00380000 (0x10000 64kB) protected
	# 57: 0x00390000 (0x10000 64kB) protected
	# 58: 0x003a0000 (0x10000 64kB) protected
	# 59: 0x003b0000 (0x10000 64kB) protected
	# 60: 0x003c0000 (0x10000 64kB) protected
	# 61: 0x003d0000 (0x10000 64kB) protected
	# 62: 0x003e0000 (0x10000 64kB) protected
	# 63: 0x003f0000 (0x10000 64kB) protected
	# 64: 0x00400000 (0x10000 64kB) protected
	# 65: 0x00410000 (0x10000 64kB) protected
	# 66: 0x00420000 (0x10000 64kB) protected
	# 67: 0x00430000 (0x10000 64kB) protected
	# 68: 0x00440000 (0x10000 64kB) protected
	# 69: 0x00450000 (0x10000 64kB) protected
	# 70: 0x00460000 (0x10000 64kB) protected
	# 71: 0x00470000 (0x10000 64kB) protected
	# 72: 0x00480000 (0x10000 64kB) protected
	# 73: 0x00490000 (0x10000 64kB) protected
	# 74: 0x004a0000 (0x10000 64kB) protected
	# 75: 0x004b0000 (0x10000 64kB) protected
	# 76: 0x004c0000 (0x10000 64kB) protected
	# 77: 0x004d0000 (0x10000 64kB) protected
	# 78: 0x004e0000 (0x10000 64kB) protected
	# 79: 0x004f0000 (0x10000 64kB) protected
	# 80: 0x00500000 (0x10000 64kB) protected
	# 81: 0x00510000 (0x10000 64kB) protected
	# 82: 0x00520000 (0x10000 64kB) protected
	# 83: 0x00530000 (0x10000 64kB) protected
	# 84: 0x00540000 (0x10000 64kB) protected
	# 85: 0x00550000 (0x10000 64kB) protected
	# 86: 0x00560000 (0x10000 64kB) protected
	# 87: 0x00570000 (0x10000 64kB) protected
	# 88: 0x00580000 (0x10000 64kB) protected
	# 89: 0x00590000 (0x10000 64kB) protected
	# 90: 0x005a0000 (0x10000 64kB) protected
	# 91: 0x005b0000 (0x10000 64kB) protected
	# 92: 0x005c0000 (0x10000 64kB) protected
	# 93: 0x005d0000 (0x10000 64kB) protected
	# 94: 0x005e0000 (0x10000 64kB) protected
	# 95: 0x005f0000 (0x10000 64kB) protected
	# 96: 0x00600000 (0x10000 64kB) protected
	# 97: 0x00610000 (0x10000 64kB) protected
	# 98: 0x00620000 (0x10000 64kB) protected
	# 99: 0x00630000 (0x10000 64kB) protected
	#100: 0x00640000 (0x10000 64kB) protected
	#101: 0x00650000 (0x10000 64kB) protected
	#102: 0x00660000 (0x10000 64kB) protected
	#103: 0x00670000 (0x10000 64kB) protected
	#104: 0x00680000 (0x10000 64kB) protected
	#105: 0x00690000 (0x10000 64kB) protected
	#106: 0x006a0000 (0x10000 64kB) protected
	#107: 0x006b0000 (0x10000 64kB) protected
	#108: 0x006c0000 (0x10000 64kB) protected
	#109: 0x006d0000 (0x10000 64kB) protected
	#110: 0x006e0000 (0x10000 64kB) protected
	#111: 0x006f0000 (0x10000 64kB) protected
	#112: 0x00700000 (0x10000 64kB) protected
	#113: 0x00710000 (0x10000 64kB) protected
	#114: 0x00720000 (0x10000 64kB) protected
	#115: 0x00730000 (0x10000 64kB) protected
	#116: 0x00740000 (0x10000 64kB) protected
	#117: 0x00750000 (0x10000 64kB) protected
	#118: 0x00760000 (0x10000 64kB) protected
	#119: 0x00770000 (0x10000 64kB) protected
	#120: 0x00780000 (0x10000 64kB) protected
	#121: 0x00790000 (0x10000 64kB) protected
	#122: 0x007a0000 (0x10000 64kB) protected
	#123: 0x007b0000 (0x10000 64kB) protected
	#124: 0x007c0000 (0x10000 64kB) protected
	#125: 0x007d0000 (0x10000 64kB) protected
	#126: 0x007e0000 (0x10000 64kB) protected
	#127: 0x007f0000 (0x10000 64kB) protected
 
ATH79 flash information:
  Device 'win w25q64fv/jv' (ID 0x001740ef)

Saving previously written u-boot area content:

> dump_image ubootbad.bin 0x9f000000 0x20000
dumped 131072 bytes in 404.372253s (0.317 KiB/s)

Remove protection from u-boot blocks in SPI flash:

> flash protect 0 0 1 off
cleared protection for sectors 0 through 1 on flash bank 0

Erase u-boot section on the flash before writing new u-boot:

> flash erase_sector 0 0 1
erased sectors 0 through 1 on flash bank 0 in 2.167238s

Write working u-boot image to the SPI flash chip:

> flash write_image uboot.bin 0xbf000000
writing 256 bytes to flash page @0x00000000
writing 256 bytes to flash page @0x00000100
writing 256 bytes to flash page @0x00000200
.....
writing 256 bytes to flash page @0x0001fc00
writing 256 bytes to flash page @0x0001fd00
writing 256 bytes to flash page @0x0001fe00
wrote 131072 bytes from file uboot.bin in 7880.783203s (0.016 KiB/s)

Now your router has restored working u-boot in the SPI flash chip, power it off, disconnect the Baite adapter, power it back on and let it boot or reflash firmware/art using tftp-serial method.

Troubleshooting:

If you get this error on openocd starting

Open On-Chip Debugger 0.10.0+dev-00916-g42cee46 (2019-06-20-15:01)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
jtag
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Versaloon(0x22)by Simon(compiled on Jun 21 2019)
Error: (null) command 0x00 failed with 0x7f
Error: Fail to initialize usbtoxxx.

it's because versaloon have some bugs. Simply run again:

openocd -f interface/vsllink.cfg -f target/ath79.cfg

If dumping image exits to prompt

> dump_image boot.bin 0x9f000000 0x20000
 
>

it may indicate problems with JTAG wiring (unconfirmed) or bug in openocd (i've compiled master version, you can try older/stable openocd release) First several attempts to read flash this way worked for me, even with adapter khz 150, but later it always failed (no matter if set khz to 1, 10 ,50, 80 or 100), sometimes it managed to read part of flash and then the process was interrupted. Slow flash reading still works, e.g: flash read_bank 0 blk1 0x00010000 0x10000

Note: When u-boot is partially damaged (but still no output on serial console) it is required to pull CS pin of the SPI flash to GND, in order to enter JTAG mode. When u-boot is completely erased, or damaged from the first sector in flash then CS pin remains low on bootstrap (after initial transition from high to low) and it is not required to short GND pin to CS for JTAG to work.

Running a 5 Ghz AP for Archer C7 versions V2, V5 (and maybe others?) will repeatedly produce the following error message after running for a couple of hours, dropping all clients and having an overall unreliable and slow connection:

ath10k_pci 0000:00:00.0: SWBA overrun on vdev 0, skipped old beacon

See also the open bug report https://github.com/openwrt/openwrt/issues/6937. This problem is still present in the latest OpenWRT version (23.05.0-rc2).

On Archer C7 v1, the Wi-Fi driver (ath10k) causes a boot loop. This 5 GHz Wi-Fi card is unsupported anyway, so the ath10k driver has been removed from release images:

• fixed in OpenWrt 18.06.3
• fixed in OpenWrt 19.07.0-rc2

Another solution would be to remove or replace the miniPCIe card of the 5 GHz Wi-Fi.

See FS#1743 and PR1349 for context and details.

If the image is not downloaded fully, or fails while downloading: Set the anticipation window of your TFTP server to 1024 bytes. This can be done in Tftpd32 by going to Settings > TFTP.

In some cases, TFTP downloads fully, but the image is not flashed on the Archer C7. That is, the leds continue cycling through the same on/off pattern. If this is your case, see detailed information bellow.

If you had a serial connection, you would probably see output like this showing the file was rejected:

Bytes transferred = 16252928 (f80000 hex) original_product_id = ffffffff original_product_ver = ffffffff original_resvered_id = ffffffff original_special_id = ▒▒▒▒▒▒▒▒▒▒▒▒ recovery_product_id = c7000002 recovery_product_ver = 01 recovery_resvered_id = 00 recovery_support_list = compare special,ret:0 auto update firmware: product id verify fail! Autobooting in 1 seconds

The normal thing is to hook up the serial interface and do some extra commands so the file isn't rejected. A simpler thing is to modify the binary you're using, to match the expected id info above. The stored information in NVRAM is corrupted above..it is all F's. Another possible corruption is all 0's. I used a hex editor (like Flexhex in Windows) and modified locations 0x40 thru 0x47, (which had the 0xc7000002, at least for a OpenWrt binary) and also 0x48 thru 0x4f. I modified those locations to also be all F. (total of 16 bytes of F).

I then renamed the binary as described elsewhere, in my case ArcherC7v2_tp_recovery.bin and redid the TFTP process. The TFTP worked, and the file “took”. This was all done without seeing the serial output..just guessing at a typical corruption/mismatch.

The led lights stop flashing if the file is accepted and loaded. That's when you know you've modified the bin with the correct id to match the corrupted values.

I've examined a number of binaries. All seem to have C7000002 00000001 in those 16 bytes. This includes the stock binaries from TP-Link. I think this explains how the TFTP process can accept either stock or OpenWrt bins if there is no NVRAM corruption. It's not some kind of exact version information for the specific binary? Somehow the value being compared gets corrupted though. In my case, all I did was aggressive/unknowing reset. I wonder if the corruption is related to trying a 30/30/30 reset?

More detail: I got back to OpenWrt with the above all F mod to a OpenWrt factory .bin. I wanted to then get back to TP-Link oem and modified (with F's) a (bootloader) stripped .bin, specifically Archer-C7-V2-FW0.0.3-stripped.bin. I loaded that with the OpenWrt webgui.

This got me to oem firmware, but every time I tried to then load more firmware with the TP-Link webgui, it failed complaining about “versions” and failed. This was true whether or not I mod'ed the .bin with F's as above.

I finally was successful loading another TP-Link oem .bin by doing another TFTP reset recovery using an unmodified ArcherC7v2_en_3_14_2_up_boot(150304).bin as the source (renamed to ArcherC7v2_tp_recovery.bin). Remember to wait for the TP-Link firmware to update after the TFTP completes. It takes a couple minutes?.

The unmodified TP-Link oem .bin successfully took, and resulted in this status in the TPLink status web page:

Firmware Version: 3.14.2 Build 150304 Rel.58409n Hardware Version: Archer C7 v2 00000000

It's interesting that the recovery firmware has a 1 in the second group of 8 bytes in the .bin. But that 1 doesn't show up in the status above? it seems like it's the same in all .bins. The “Hardware Version” status reports all 0's after the obvious C7 and 2. I'm not sure the TP-LINK firmware gets that Hardware Version. Especially if it's locked to the hardware, not the firmware?? Or can firmware change it?

I include all this detail, because the path from using modified OpenWrt .bins (with F's) to similarly modified TP-Link oem .bin (stripped) to using unmodified TP-Link oem firmware (not stripped), was more of a hassle than I expected. It's possible the 2nd “.bin with bootloader” from TP-Link overwrote some NVRAM locations that the initial boot-stripped TP-Link .bin didn't, because now I can load a variety of unmodified TP-Link oem .bins from the TP-Link webgui, when I couldn't before.

It was critical that the unmodified second TP-Link .bin was loaded using the TFTP recovery mechanism, not the webgui. The last TP-Link oem I loaded resulted in this version status. I used the oem webgui to load ArcherC7v2_en_us_180114.bin

Firmware Version: 3.15.3 Build 180114 Rel.39265n Hardware Version: Archer C7 v2 00000000

Pro tip: Sometimes you need your computer to have a 192.168.0.x ip address, and sometimes 192.168.1.x. You can speed up the process of setting up the 192.168.0.66 TFTP server, and testing 192.168.0.1 or 192.168.1.1 responses, by having two laptops plugged into the back of the Archer C7. One setup manually for a 192.168.0.x ip, and the other setup for a 192.168.1.x ip.

This way, rather that constantly wrestling with changing your IP address on a single computer, you just use whichever laptop has the right IP address for whatever the recovery step needs. I actually had a Windows computer acting as the TFTP server, and a Linux laptop for the 192.168.1.x work. I also could unplug them and enable their wifi for internet access when necessary for getting binaries or reading.

Also note: the latest firmware from TP-Link may complain about versions when loading alternate firmware or earlier oem versions from its webgui. I found I had to revert to ArcherC7v2_en_3_14_2_up_boot(150304).bin with TFTP recovery in order to experiment with DDWRT after all this. I successfully loaded DDWRT firmware with the TP-Link oem webgui when I used that particular oem version. I forget if I was able to use the webgui on the newest TP-Link firmware to load OpenWrt originally. In any case, the oem version mentioned works for that.

Having trouble downloading bin file via TFTP on Archer c7 v5 (EU) - read this

I had trouble downloading BIN file via TFTP on Archer c7 v5. File was downloaded but then nothing happened. I was stuck for ages. I have searched and searched, until I finally found a way to TFTP file to router that has accepted it and started flashing process. A little background: I was on version 19 OPENWRT during update something went wrong. First Luci stopped working, then after I flashed new image with SSH router was bricked. The initial (default) settings of TFTP64 program worked in a strange way, so I was mislead (see at the bottom).

Please follow this steps exactly and you could unbrick your router. Please note this solution is based for Windows 10 PC.

Download TFTP64 program (link is already posted above) and install this program on Win 10 PC. Set IP = 192.168.0.66 and Mask=255.255.255.0 on your LAN. Disable firewall. Start the TFTP64 program.

Click on Settings.

Make sure your window is exactly the same as above, then click on “Global” TAB.

Check only TFTP server. Hit OK and restart the TFTP64 program. Now window should look like this when you re-open TFTP64 program (note TFTP is ready on 192.168.0.66).

Click on Browse and point to a location where file ArcherC7v5_tp_recovery.bin is located.

Plug UTP cable into LAN port #1. Pres & hold reset button for approximately 5 sec while powering on your router. WPS lights should lit up (arrows up/down) indicating that router will look for specified file. TFTP process will start and file will be downloaded to router. My router needed approx. 7 sec to download a file. Then Power light kept blinking and WPS light (arrows up/down) stayed lit for approx 80 sec (till flashing is complete). This is how user can confirm (status lights Power and up/down arrows) that BIN file is being flashed into Archer c7 v5 (EU). The file I was downloading was original firmware for TP-LINK Archer C7 v5 (EU), but I later confirmed that it works also with openWrt ver 21.BIN file.

Let me explain what happened and how I was mislead by lights on the first place. When this settings in TFTP64 program were not set as described above (set as default). The file was downloaded to the router. But the file transfer took 1-2 sec (definitely quicker). After transfer, the power light blinked ONLY ONCE and stayed lit. Thus indicating - the router rejected BIN file, due to download errors (Presumably, I didn't have a USB console to confirm this)

I hope this information helps someone, as I spent 3 days struggling to TFTP a file into a router.

The following is the dmesg output from OpenWrt 18.06.1 successfully booted on a TP-Link Archer c7 v2.

How to add tags