TFTP download from TP-Link Archer C2 does not work properly

pbasista · May 31, 2020, 9:19pm

Hi,

I have two TP-Link Archer C2(EU) routers, both at hardware revisions 1.1. Their serial numbers differ by about 1 million.

I have tried to flash OpenWRT on the one with the lower serial number using the instructions from the official OpenWRT table of hardware page for TP-Link Archer C2. It worked well and I was able to install OpenWRT successfully.

Then I have tried to do the same with another device, i.e. the one with a higher serial number. But I was unsuccessful because the TFTP download never finished successfully.

The behavior is that the TFTP transfer starts, but is very slow. After about 5-10 seconds and transferring on average about 300 blocks (sometimes only 30, sometimes even 500) of size 512 B (up to ~150 KB), it stops and the regular boot process resumes. Using the same computer, the same TFTP server software with the same settings, the same cable and the same power adapter on the other TP-Link Archer C2 device (i.e. the one with the lower serial number), the device downloads the entire file (~8 MiB) in ~2-3 seconds.

The official OpenWRT table of hardware for TP-Link Archer C2 mentions that some users have reported similar issues and that they could potentially be resolved by changing some TFTP settings or by lowering the network transfer speed. However, from my experiments, changing the network speed has little to no impact and the device still never finishes the TFTP download. I am using the atftpd TFTP server and I have also tried to experiment with most of its settings. But no configuration that I have used resulted in any significant change in the router's behavior. It never proceeds beyond downloading the first a few hundred KiB from the TFTP server. At the same time, the other device, i.e. the one with the lower serial number, can download the entire firmware quickly and without any issue with almost any TFTP server settings.

Despite the fact that the device with a higher serial number cannot successfully perform the TFTP download, it can be used with the stock firmware and everything seems to work normally. I can also change between the stock firmware versions via the web interface without any issue. The TFTP downloading of the firmware, however, does not work properly with any of the official firmware versions.

I would like to ask if someone has perhaps experienced a similar behavior. If yes, have you managed to resolve it?

Thank you.

slh · May 31, 2020, 11:00pm

Your chances might increase by putting a simple unmanaged switch between router and computer, as this can help with link training issues - it really shouldn't here, but it's easy to try.

pbasista · June 1, 2020, 7:49am

Thank you for the suggestion. I have tried that already with TP-Link TL-SG108E switch, but it did not seem to make a difference.

pbasista · December 22, 2020, 9:26pm

I would like to add that I have also tried to flash the firmware via TFTP to this device by using a Tenda S5 switch, as well as the switch within the TP-Link TL-WR841N router in between the TFTP server and the device. The device with a higher serial number has, however, behaved in the same way as before with a more modern gigabit switch, i.e. the firmware download has failed to finish.

While using these lower-speed switches, I have also tried to change the ethernet link speed and duplex mode of the TFTP server's network interface from 1000 Mb/s full duplex to 10 Mb/s half duplex. It did not make any difference.

So, at least from my experience, putting new or old switches on the link or artificially lowering the link speed has no impact on the actual outcome of the TFTP download method on this device. Some devices are seemingly able to do it successfully regardless of the network conditions while some others are not.

4Style · January 6, 2021, 9:14am

Hmm that's sad to hear.
I've just tried to flash the Archer C2 with OpenWRT because the 5Ghz issues seem to be fixed now even in the stable releases.
But i was experiencing the same issues as you @pbasista.
Wireshark is showing that a few packets (for me it's mostly just around 100) are transmitted and then the computer tries re-transmitting the same packet over and over again until the router restarts without having OpenWRT installed.
Chaning link speed to 10mbit/s half duplex or putting my TP-Link switch in between did not make any difference (without the switch the router did not restart, but the transmission was halted either) .

So it seems to me that I also have an unflashable device here
That's quite sad because i had high hopes in OpenWRT which would allow me to enable WPA3 security...

If somebody has any ideas that I could try out, please let me know!

pbasista · January 6, 2021, 9:36am

Perhaps we can at least try to estimate which of these devices are likely to have issues with the TFTP flashing by trying to see if there is a pattern within the serial numbers of the affected devices.

The serial number of my device which has TFTP flashing issues is 2161374002651.

frollic · January 6, 2021, 10:21am

You could always try to connect the serial console, then you'd be able to to see
what the actual problem is, and perhaps initiate the flash from u-boot.

problem · January 6, 2021, 6:16pm

Hello I just bought a used archer C2 and have the same problem.. S/N: 215B024013117
How to initiate the process from serial interface? What are the address spaces?

frollic · January 6, 2021, 6:40pm

depends on what the u-boot is capable of.

interrupt the auto boot sequence, then use the commands tftp and bootm, to transfer and
boot the transferred image.

problem · January 6, 2021, 6:59pm

Thank you for the reply, but fortunately I have managed to complete the transfer. I reflashed the firmware to another version and tried to enable "anticipation window" option with value 1000 in tftpd64. Not sure what helped though.

pbasista · January 7, 2021, 12:43am

Pressing "4" during the early boot stage launches the U-Boot prompt. Maybe there are other ways but that is what is mentioned on the device's Table of Hardware page and I can confirm that it works.

Here is the serial console's output during my device's unsuccessful TFTP recovery attempt:

..................................................
starting recovery...
TODO, Read MAC Address from Flash

rt_rtl8367_init(1363):Begin

RTL8367RB is ready now!
rt_rtl8367_init(1404):Call Func rt_rtl8367_enableRgmii()
rt_rtl8367_enableRgmii(931):Begin

 netboot_common, argc= 3 

 NetTxPacket = 0x83FE5800 

 KSEG1ADDR(NetTxPacket) = 0xA3FE5800 

 NetLoop,call eth_halt ! 

 NetLoop,call eth_init ! 
Trying Eth0 (10/100-M)

 Waitting for RX_DMA_BUSY status Start... done


 ETH_STATE_ACTIVE!! 
TFTP from server 192.168.0.66; our IP address is 192.168.0.1
Filename 'ArcherC2V1_tp_recovery.bin'.

 TIMEOUT_COUNT=10,Load address: 0x80060000
Loading: T T T Got ARP REPLY, set server/gtwy eth addr (74:d4:35:e7:5d:9e)
Got it
#
 Same block again; ignore it 
T ###
 Same block again; ignore it 
T ##
 Same block again; ignore it 
T 
 Same block again; ignore it 
T ##Got ARP REQUEST, return our IP

 Same block again; ignore it 
T #
 Same block again; ignore it 
T ##
 Same block again; ignore it 
T #######
 Same block again; ignore it 

Retry count exceeded; starting again
do_bootm:argc=2, addr=0xbc020000
## Booting image at bc020000 ...
   Uncompressing Kernel Image ...

The "T" letters indicate timeouts. The U-Boot FAQ page contains an entry related to TFTP timeouts which suggests that they are typically caused by the misconfiguration of the duplex mode on the board's MAC chip. I did not look into it further yet but perhaps it is possible to reconfigure it manually from within U-Boot at first and then perform the transfer.

One other possibility, which I also did not look into yet, might be to transfer the firmware file to the device over the serial console.

They are again listed on the device's Table of Hardware page. In my case:

MT7620 # bdinfo
boot_params = 0x83F4FFB0
memstart    = 0x80000000
memsize     = 0x04000000
flashstart  = 0x00000000
flashsize   = 0x00800000
flashoffset = 0x00000000
ethaddr     = 00:00:0A:EB:13:09
ip_addr     = 192.168.0.1
baudrate    = 115200 bps

frollic · January 7, 2021, 7:37am

Another option would be to upgrade u-boot, to be able to handle USB storage, and flash the new image from a flash drive.

Since you have the serial console, try upgrading to the newest c2 fw available, it might contain a newer version of uboot, fixing the time out issue.
Or try to downgrade.

Upgrading uboot from within uboot is also an option, yet risky.

Do read the TFTP info from the link below, it specifically mention timeouts.

4Style · January 7, 2021, 10:36am

Glad to hear that you managed to upgrade your Archer C2 to OpenWRT.
Could you tell me which TP-Link firmware version you flashed? Unfortunately i don't have the skill (and i guess equipment too) to connect via serial console to the router.

And is this tip with the anticipation window also relevant if you are using a linux TFTP server (like tftp-hpa)?
Then i will try this out when i'm back home and also post the serial number of my router.

pbasista · January 7, 2021, 6:31pm

The necessary equipment is relatively inexpensive and consists of an USB to TTL UART adapter, e.g. this one and some jumper wires with male connectors at one end for conveniently making the connection, e.g. those ones. No soldering is necessary for this particular device.

Most probably yes. I am not sure what "anticipation window" means in this context but maybe it refers to the retransmission period, i.e. the time period during which the TFTP server waits to receive the reply from the client before transmitting the same packet again. In atftpd, for instance, this can be controlled by the --retry-timeout argument. In tftpd-hpa, it can be controlled by the --retransmit argument.

I have, however, tried to experiment with it and it resulted in no observable change in the router's behavior during the TFTP firmware download. The one router which had issues with the default settings had roughly the same issues with larger or smaller retransmission periods as well, at least in my case.

As mentioned earlier, I have already tried all the officially available firmware revisions from TP-Link and the outcome was always the same:

I am familiar with the information mentioned there but as mentioned in the original message of this thread, it did not help in my case.

pbasista · January 10, 2021, 10:42am

I have been able to successfully flash OpenWrt on the TP-Link Archer C2 device whose TFTP recovery does not work properly. I have used the device's serial console to transfer the OpenWrt firmware to the router's memory. Then I have manually copied the transferred firmware from memory to flash.

In more detail

I have used the following steps:

Connect the device's serial console to a terminal emulator on a host computer.
Power on the device. Keep pressing the "t" key during the early boot stage. This will stop the boot process and launch the U-Boot prompt.
Load an OpenWrt sysupgrade image for this device, e.g. this one, to the router's memory over serial console. Use the Kermit program on the host computer to transfer the file.

MT7620 # loadb
## Ready for binary (kermit) download to 0x80100000 at 115200 bps...
## Total Size      = 0x003f0110 = 4129040 Bytes  
## Start Addr      = 0x80100000

Erase the flash memory used for the "firmware" mtd partition while keeping the flash memory used for the bootloader unchanged. The correct offset and size can be obtained and calculated e.g. from the flash layout section of the device's Table of Hardware page. This step might be optional but I am not fully sure.

MT7620 # erase tplink 0x20000 0x7a0000

 Erase flash !!
From 0x20000 length 0x7A0000
raspi_erase: offs:20000 len:7a0000
..........................................................................................................................

Double check whether the new firmware has indeed been correctly loaded to the device's memory at the expected address.

MT7620 # md 0x80100000
80100000: 00000003 2e726576 302e3220 ffffff00    ....ver. 2.0....
80100010: ffffffff ffffffff ffffffff ffffffff    ................
80100020: ffffffff ffffffff ffffffff ffffffff    ................
80100030: ffffffff 010050c7 32000000 00000000    .....P.....2....
80100040: 7d5d75d5 d5cf2041 8bbcb69d 6fdae3c8    .u]}A .........o
80100050: 00000000 ffffffff ffffffff ffffffff    ................
80100060: ffffffff ffffffff 80000000 80000000    ................
80100070: 00007a00 00020000 f4de1700 f4e01700    .z..............
80100080: 40ef2600 00000000 00000000 0001aa55    .&.@........U...
80100090: 000000a5 ffffffff ffffffff ffffffff    ................
801000a0: ffffffff ffffffff ffffffff ffffffff    ................
801000b0: ffffffff ffffffff ffffffff ffffffff    ................
801000c0: ffffffff ffffffff ffffffff ffffffff    ................
801000d0: ffffffff ffffffff ffffffff ffffffff    ................
801000e0: ffffffff ffffffff ffffffff ffffffff    ................
801000f0: ffffffff ffffffff ffffffff ffffffff    ................

Copy the newly loaded firmware from memory to the beginning of the "firmware" mtd partition in flash mentioned earlier while keeping the part of the flash occupied by the bootloader unchanged.

MT7620 # cp.b 0x80100000 0x20000 0x3f0110

 Copy 0x80100000 to 0x00020000, count 0x3F0110....
raspi_write: to:20000 len:3f0110
..........................................................................................................................

Reboot the router.

MT7620 # reset

These steps have been inspired by this message in the old OpenWrt forum by user bd03E about adding early support for TP-Link Archer C2.

When using this approach, it is important to not overwrite the bootloader so that in case of a failure, the device will still remain bootable and the entire process could be repeated.

The erase and cp U-Boot commands have several custom variations:

MT7620 # help erase
erase
erase all
    - erase all FLASH banks
erase uboot
    - erase uboot block
erase linux
    - erase linux kernel block
erase tplink
   - erase blocks at addr with length
MT7620 # help cp
cp
cp.uboot
    - copy uboot block
cp.linux
    - copy linux kernel block
cp.b
    - src dst count.copy binary from source to target with count length.

which have been most likely designed to work well with the TFTP upgrade. However, they probably erase or copy data from hardcoded memory locations so I would avoid using them and only use those commands where the source and destination address can be explicitly specified.

Regarding the process of actually sending the firmware to the device over a serial console, it is described in general e.g. here. I have used the C-Kermit program with configuration as described in the U-Boot manual. It takes ~10 minutes to transfer ~5 MiB of data to this device using these settings.

Other approaches

I have also tried several other approaches which turned out to be unsuccessful, at least in my case. I will list them here for reference.

Using the original TP-Link firmware to flash a new firmware manually.
Despite the fact that it is possible log in as root to the device's original firmware (username: admin, password: 1234) both over the serial console and over ssh or telnet, I was not able to flash a new firmware from there because I could not figure out how to read and write the /dev/mtd* files. Perhaps some external binary could be used for this purpose but I did not look into that.
Using a different version of U-Boot.
I was able to load the same version of U-Boot into memory and then use the U-Boot's go command to run it. It worked well but I did not have a different version of U-Boot to try. I have, however, compared the U-Boot versions on the router whose TFTP download works with the one on which it does not work properly. They turned out to be exactly the same. So I assume that the issues with the TFTP download are caused by some subtle hardware differences between the two routers. Those differences then perhaps might cause U-Boot's TFTP download to work on one device but not on the other.
Using the U-Boot bootloader to load a new firmware into memory and boot from it directly without having to write it to the flash memory first.
As described above, I was able to load the firmware into the memory over the serial console. But I was not able to boot the Linux kernel directly from memory because of LZMA errors. The same kernel, however, works well when copied to flash. I am not sure why.

MT7620 # bootm
do_bootm:argc=1, addr=0x80100000
## Booting image at 80100000 ...
   Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover

To summarize, the router works well with OpenWrt now. The issue with TFTP download does not affect the router's ability to erase flash or copy new data to it from within the U-Boot. So, the described work-around is based on replacing the TFTP download step with the download over the serial console.

4Style · January 11, 2021, 11:40pm

Thanks for the really detailed guide, which i would love to try out.
But i guess when you are talking about accessing the serial console, i will have to open up my router and solder some stuff right?
Unfortunately that's a bit too risky for me, I will try the other methods (anticipation window and other firmware versions) when i have time.

pbasista · January 12, 2021, 12:07am

Open up the case of the router, yes. Perform soldering, no. As is mentioned above:

The serial connector on the board of this router is well exposed and consists of 4 contact holes on the board. You can simply insert some jumper wires with male ends into the holes in order to make a connection. From my experience, such a connection is very reliable as long as the jumper wires do not move.

mk24 · January 12, 2021, 12:46am

That requires an "initramfs" build, which you can get from the snapshots directory. Factory and sysupgrade builds will not boot from RAM.

And it is my preferred method to debrick since you don't have to erase flash manually which a mistake in the address or length would cause a severe problem.

pbasista · January 12, 2021, 7:41am

Yes, I am aware of that. I have tried to load this kind of image to the device's 0x80100000 address and then boot from it but it did not work. There was an LZMA error 1.

Why do you believe that this is the case?

The Archer C2's sysupgrade image, for instance, contains the linux kernel at its beginning. So, I think that it should be possible to load it into the memory and then boot from it in the same way as booting from the initramfs image. The sqashfs filesystem at the end of the sysupgrade image would simply be ignored in that case.

The factory images are generally very device-specific so they may not be bootable in the same way as the other kinds of images, i.e. by loading the kernel from their beginning. The reason is that they may contain e.g. the bootloader at the beginning instead the Linux kernel. However, at least in case of Archer C2, the factory image also contains the Linux kernel at its beginning, for some reason. Its content is almost exactly the same as the content of the squashfs image except for a few bytes in the header and a few bytes at the end where the sysupgrade image contains some metadata while the factory image does not. The factory image then also contains a lot of binary ones (i.e. 0xff) at the end as padding so that its size would be 0x7A0000.

4Style · January 12, 2021, 8:12am

Opps sorry, seems like I've somehow overread this part of your last reply.
Actually I have a USB to Uart adapter lying around here, maybe I can also find some jumper wires,then I will give it a try.
Thanks again