Wr940n v5 (ES) bricked. Trying Serial TTL and TFTP

Inspired by topic Porting Firmware to TP-Link Archer C20 v5
It's very possible that your board have dual bootloader configuration too.
So you can try next procudere for tp_recovery.bin creation:

dd if="wr940nv5_eu_3_18_1_up_boot(180514).bin" bs=512 skip=1 > tp_recovery.old
dd if=/dev/zero of=pad192k.bin bs=192k count=1
cat pad192k.bin tp_recovery.old > tp_recovery.bin

Or simply use mktftpimg utility of @dxdt from

Hi Serge, thanks for your help. Unfortunately it didn't work :frowning:. However I think that the art is in discover the magic numbers to skip and merge the right binary.

Looking to the referred post I discovered the binwalk tool for binary files analysis. Here are the results of some binaries downloaded from tplink.

Archer_C20v5_US

$ binwalk -e Archer_C20v5_US_0.9.1_4.16_up_boot\[181213-rel33336\].bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
80960         0x13C40         U-Boot version string, "U-Boot 1.1.3 (Dec 13 2018 - 09:07:10)"
132096        0x20400         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3642448 bytes
1442304       0x160200        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 5150316 bytes, 742 inodes, blocksize: 131072 bytes, created: 2018-12-13 01:16:29

wr940nv5_us

$ binwalk -e wr940nv5_us_3_20_1_up_boot\(200316\).bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             TP-Link firmware header, firmware version: 0.-6164.3, image version: "", product ID: 0x0, product version: 155189252, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 4063744, kernel length: 512, rootfs offset: 866618, rootfs length: 917504, bootloader offset: 3014656, bootloader length: 0
15552         0x3CC0          U-Boot version string, "U-Boot 1.1.4 (Mar 16 2020 - 09:26:38)"
15600         0x3CF0          CRC32 polynomial table, big endian
16900         0x4204          uImage header, header size: 64 bytes, header CRC: 0xCB6027D7, created: 2020-03-16 01:26:38, image size: 42920 bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0x11F3A251, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
16964         0x4244          LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 114016 bytes
131584        0x20200         TP-Link firmware header, firmware version: 0.0.3, image version: "", product ID: 0x0, product version: 155189252, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 3932160, kernel length: 512, rootfs offset: 866618, rootfs length: 917504, bootloader offset: 3014656, bootloader length: 0
132096        0x20400         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 2496348 bytes
333162        0x5156A         MPEG transport stream data
1049088       0x100200        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 2989254 bytes, 690 inodes, blocksize: 262144 bytes, created: 2020-03-16 01:33:58

wr940nv5_EU

$ binwalk -e wr940nv5_eu_3_20_1_up_boot\(200316\).bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             TP-Link firmware header, firmware version: 0.-6164.3, image version: "", product ID: 0x0, product version: 155189252, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 4063744, kernel length: 512, rootfs offset: 866618, rootfs length: 917504, bootloader offset: 3014656, bootloader length: 0
15552         0x3CC0          U-Boot version string, "U-Boot 1.1.4 (Mar 16 2020 - 09:26:38)"
15600         0x3CF0          CRC32 polynomial table, big endian
16900         0x4204          uImage header, header size: 64 bytes, header CRC: 0xCB6027D7, created: 2020-03-16 01:26:38, image size: 42920 bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0x11F3A251, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
16964         0x4244          LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 114016 bytes
131584        0x20200         TP-Link firmware header, firmware version: 0.0.3, image version: "", product ID: 0x0, product version: 155189252, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 3932160, kernel length: 512, rootfs offset: 866618, rootfs length: 917504, bootloader offset: 3014656, bootloader length: 0
132096        0x20400         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 2496348 bytes
333162        0x5156A         MPEG transport stream data
1049088       0x100200        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 2989254 bytes, 690 inodes, blocksize: 262144 bytes, created: 2020-03-16 01:33:58

I am working in guessing why for Archer C20 they skip 192k bytes ... and which is the amount for wr940 V5 ES

Here what @ashegoulding says in his/her repo:

512 is the size of header( sizeof(struct fw_header) is 512: exb A, exb B). The actual binary that the hardware loads starts after the header.

196608 (0x30000) is the size of the first boot loader region. The TFTP recovery program skips 196608 bytes of the downloaded image when copying into the flash. Stupid design if you ask me. This number(0x30000) appears on the serial output when performing TFTP reset. 0x30000 is probably the size of the first boot loader for all variants. But you can only find this out if you have the serial console. If you think it's not for your variant, well. Shotgun it(trial and error). I highly doubt it's other than 0x30000, though.

I think that these numbers explain your answer @123serge123

Keep trying ...

Which firmware did you flash exactly? Is it possible that you replaced bootloader and changed recovery method too?

I guess not, but not sure ... this is my very first brick :frowning:

The serial port has activity, but as I said, strange, garbage or something in the middle. I measure with an oscilloscope and verified the baudrate (115200 bps). And the TFTP capability of the bootloader is fine. I am not able to perform any other test by the moment. Do you understand why 192k in the method you suggested? Thanks!

At this time I know three method of preparing recovery image form original vendor firmware file containing word uboot in filename. Just to simplify next explaination we assume that the file
"wr940nv5_eu_3_18_1_up_boot(180514).bin" is splitted into parts:

dd if="wr940nv5_eu_3_18_1_up_boot(180514).bin" bs=512 count=1 > vendorheader.bin
dd if="wr940nv5_eu_3_18_1_up_boot(180514).bin" bs=512 skip=1 count=256 > bootloader.bin
dd if="wr940nv5_eu_3_18_1_up_boot(180514).bin" bs=512 skip=257 > firmware.bin

So the three methods:

  1. Simply rename file firmware.bin into tp_recovery.bin or ${MODEL_NAME}_tp_recovery.bin.
  2. Concatenation of files bootloader.bin and firmware.bin (cat bootloader.bin firmware.bin >tp_recovery.bin) is renamed into tp_recovery.bin or ${MODEL_NAME}_tp_recovery.bin.
  3. Concatenation of files pad192k.bin, bootloader.bin and firmware.bin s renamed into tp_recovery.bin or ${MODEL_NAME}_tp_recovery.bin for two stage/step bootloader. Where padd192k.bin is any file of size 192k exactly (usually result of dd if=/dev/zero of=pad192k.bin bs=192k count=1).

Some comments to point 3: so called bootloader step 1 or bootloader0.bin is never overwritten by firmware.bin and have size 192k exactly (I think that I answer your question? :)). And in this case real flash layout is:
0x00000000 - 0x00030000: bootloader0.bin
0x00030000 - 0x00050000: bootloader.bin
0x00050000 - 0x003f0000: firmware.bin
0x003f0000 - 0x00400000: art.bin
What is the function of bootloader0.bin knows only tplink programmers. May be it check integrity of bootloader.bin and start http (Http,Carl! :)) recovery procedure if fail.
I don't find description of wr940v5 in openwrt source so I don't exclude this variant.
U-u-uh. End of comment :slight_smile: .

Now bootloader (that currently flashed and run) go into game. If it's locked (see NOTES https://openwrt.org/toh/tp-link/tl-wdr4300) or check hardware revision/regional code it just ignore recovery image :frowning:
BTW you don't answer which firmware brick your device.
So without serial consloe logs we can play "угадайка" (as Rassians say) forever.

I think that you cross tx/rx?
UPDATE. I don't link google translation of "угадайка" . Read "repeating tries to guess" instead :slight_smile:

Thanks for your help Serge! I will answer your questions first:

I guess (not sure really) it was the US stock firmware from TP link. As other users told me here, if the TFTP capability remain when resetting, the first bootloader is fine. THen I read in other posts that TPlinks routers come with two bootloaders. That keeps my hope high enough in order to keep trying.

I don't think so, why do you believe that? but I think that the first things I tried was trying in both ways, there is only one chance to see activity in my console, right? Tx_R (router) Rx_C (computer) I mean.
Maybe I am not understanding your comment, let me know.

I will read your explanation carefully, now I have to play with my kids, I was showing your russian explanation :wink:

Thanks again
Mariano.

That firmware have name and url? I want to inspect it.

Yes. I mean this case.

Ok. Now we assume that your router is locked to US revision.
Do you try to restore tplink US firmware? Or openwrt US firmware?
BTW from openwrt command line you can simply replace bootloader and firmware to any regional version.

This is the firmware, here you can download

https://static.tp-link.com/2020/202004/20200426/TL-WR940N(US)_V5_200316.zip

yes, I tried without success. The strange thing, as I described in the first post, is that I flashed openwrt
940n v4 and worked fine in my v5 router (v4 and v5 are the same for openwrt). Then, I decided to go back to stock firmware, and then bricked the router, probably with the US V5 firmware. When I tried via TFPT to flash openwrt V4 again, it didn't work, I don't know why, and this make me think that the router is gone. However, if the TFTP client works, maybe it is not all lost, I hope ...

Things that I did not try: my router is 940n V5 ES region version (latam region). TPlink is working since a couple of weeks in posting in their website an ES specific version of the firmware. They didn't publish any firmware for my hardware and region version. When this firmware would be available, maybe the definitive test could be performed.

Best
M.

Great! I am testing the 3 methods you described. Thanks

Can you show tftp server logs?

I tried the 3 methods without success. :frowning:

Regarding this, I follow a tcpdump src 192.168.0.86, monitor the transmission of the date and crossfinger. Do you need anything else?

That router start connection to tftp server you can see server's log, can't you? I'd like to see the logs.

Ok here what I have:

● tftpd-hpa.service - LSB: HPA's tftp server
Loaded: loaded (/etc/init.d/tftpd-hpa; generated)
Active: active (running) since Sat 2020-07-25 13:58:45 -03; 3 days ago
Docs: man:systemd-sysv-generator(8)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/tftpd-hpa.service
└─30221 /usr/sbin/in.tftpd --listen --user tftp --address :69 --secure -c -vvv /home/mariano/tftp

jul 25 18:29:19 nbmec in.tftpd[9317]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 25 18:33:03 nbmec in.tftpd[9551]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 25 18:35:32 nbmec in.tftpd[9846]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 26 09:34:42 nbmec in.tftpd[19074]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 26 09:36:52 nbmec in.tftpd[19140]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 27 01:32:39 nbmec in.tftpd[23184]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 29 00:17:10 nbmec in.tftpd[1085]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 29 00:20:32 nbmec in.tftpd[1231]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 29 00:25:15 nbmec in.tftpd[1674]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin
jul 29 00:26:50 nbmec in.tftpd[1717]: RRQ from 192.168.0.86 filename wr940nv5_tp_recovery.bin

I hope you rename tp_recovery.bin into wr940nv5_tp_recovery.bin?

1 Like

Yes hahaha. I told you that I monitored the datagrams with tcpdump

Just for test can you try very old US firmware
https://static.tp-link.com/TL-WR940N(US)_V5_161019.zip
method 1?

Thanks @bakemono and @123serge123 for your help. Despite the broken link of the last answer of Serge, sereved me to look for the file, and looking for that file I laterally found an V5 ES version from 2016 which eventually let me finish the TFTP flash procedure. I leave here a link to it, since there is not official firmware available in TPlink web page for the V5 ES variant. Thanks all again!

https://drive.google.com/file/d/1qXPPwZL1UftPU0-B7VqY6GTmjGHhd3yy/view?usp=sharing

One last thing about the serial Port. Right after the flashing, the serial port started to work. I only managed to press a couple of times the reset button, reading in the terminal the legend "Reset button press" and "Reset button released". Thats all, after the power off-on cycle the serial port became puzzled again, maybe the guys from TPlink disabled the serail port access? I don't really know, but I guess yes.

1 Like

With MediaTek chips, sometimes the baud rate is 57600 instead of 115200.

1 Like

I've unpacked uboot code from wr940nv5_us_3_17_1_up_boot(161019).bin and see that uboot check product_id and product_ver of recovery image and original. It ignore recovery image if this verification fail.
Then with mktplinfw utility I compare files

$ mktplinkfw -i wr940nv5_us_3_17_1_up_boot\(161019\).bin 
File name              : wr940nv5_us_3_17_1_up_boot(161019).bin
File size              : 0x003e0200 /  4063744 bytes
Version 1 Header size  : 0x00000200 /      512 bytes
Header MD5Sum1         : 39 a3 1b 5c 4b 47 a4 9f a5 d4 51 ae 5d 0d 93 33 (ok)
Header MD5Sum2         : fa 29 ee c7 fa 69 57 5e ab c4 9f 61 74 55 f5 ac (purpose yet unknown, unchecked here)

Vendor name            : TP-LINK Technologies
Firmware version       : ver. 1.0
Hardware ID            : 0x09400004
Hardware Revision      : 0x00000001
Region code            : 0x00000000

Kernel data offset     : 0x00000200 /      512 bytes
Kernel data length     : 0x000d355c /   865628 bytes
Kernel load address    : 0x80002000
Kernel entry point     : 0x801cea10
Rootfs data offset     : 0x00100000 /  1048576 bytes
Rootfs data length     : 0x002c0000 /  2883584 bytes
Boot loader data offset: 0x00000000 /        0 bytes
Boot loader data length: 0x0000e763 /    59235 bytes
Total firmware length  : 0x003e0200 /  4063744 bytes

and

$ mktplinkfw -i wr940nv5_es_3_17_1_up_boot\(161121\).bin
File name              : wr940nv5_es_3_17_1_up_boot(161121).bin
File size              : 0x003e0200 /  4063744 bytes
Version 1 Header size  : 0x00000200 /      512 bytes
Header MD5Sum1         : 28 4c 5d 11 46 c6 0b 06 f2 68 23 59 2b 67 6a a6 (ok)
Header MD5Sum2         : 44 13 f0 dc ad b6 c9 fc 37 34 cc b4 a4 f7 08 ad (purpose yet unknown, unchecked here)

Vendor name            : TP-LINK Technologies
Firmware version       : ver. 1.0
Hardware ID            : 0x09400005
Hardware Revision      : 0x00000001
Region code            : 0x00000000

Kernel data offset     : 0x00000200 /      512 bytes
Kernel data length     : 0x000d3583 /   865667 bytes
Kernel load address    : 0x80002000
Kernel entry point     : 0x801cea10
Rootfs data offset     : 0x00100000 /  1048576 bytes
Rootfs data length     : 0x002c0000 /  2883584 bytes
Boot loader data offset: 0x00000000 /        0 bytes
Boot loader data length: 0x0000e764 /    59236 bytes
Total firmware length  : 0x003e0200 /  4063744 bytes

Pay attention that "Hardware ID" and "Hardware Revision" are different.

1 Like

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