Alternative title: How to avoid bricking your router.
This is a published draft version for public review. Comments welcome.
When I started to develop a customized build of OpenWRT CC15.05/15.05.1 for my TL-WR1043NDv1, I ran into some problems. I bricked some of my routers. It also happened to me with the current the LEDE 17.01-rc2. Let my start from the beginning:
The following hints come without any guarantee to work as aspected. By following these you will void warranties given to you by the manufacturer. You agree not to hold me liable for any damages that may occur from following these -probably incomplete- instructions.
These instructions are based on my own experiences and are published AS IS.
All trademarks remain property of their respective holders, and are used only to directly describe the products being provided.
For those, who never heard of customized builds in this context, OpenWRT provides an “Image Builder”. In short, these are are a bunch of scripts and Makefiles, that will allow you to combine precompiled pieces of software, individual files, such as configuration data or additional software precompiled by you and files from OpenWRTs packages repository into a flashable firmware file.
This works well most of the time, but errors happen, if either the router is very low on memory during the flashing procedure or if you failed to include important packages correctly. In these cases, the kernel is likely to boot, but the init process will fail. Most likely it won´t find the squashfs partition. This will cause a reboot loop or a stalled router.
Bricked router – The remedy
If that happens you need to debrick your router. There are several ways to do that – beginning with the most complicated and most unlikely variant:
- With a Flash-Chip replacement (never seen that)
- From a serial console (you don’t need to be an expert, but it requires you to be skilled in soldering)
- you need to solder pins to the routers PCB
- you need a voltage level shifter – “TTL-cable“
- Via network TFTP (most easy)
- connect the PC or another router providing a TFTP server and the necessary recocery firmware by cable and power up with the reset button pressed.
This article will focus on how to avoid the neccessity for applying to the first two methods.
There is a good and a bad message –
The good one first: the TL-WR1043NDv1 supports Ethernet TFTP flashing in correctly flashed new firmwares.
The bad one follows: Old firmwares have old bootloaders (U-Boot 1.1.4 dated back to 2009), that don’t support it… Even if you have a newer original TP-LINK firmware installed, that does not necessarily mean, the boot loader was updated to U-Boot 1.1.4 dated back to 2014 (that version is capable of doing TFTP updates).
How the bootloader’s TFTP works
That works quite easily – the TFTP server needs to be at 192.168.0.66/24 and will provide a firmware file called “wr1043nv1_tp_recovery.bin”. This file can be an original firmware file without “boot” in it’s unmodified name or even a *factory.bin from one of the *WRTs (of course compiled for the TL-WR1043NDv1). The TFTP routine will then be triggered by powering on the router while pressing the reset button. (“Reset” is the hidden button in the back of the device, that is located near the 12V power socket).
It is advised to use a simple ethernet switch in between the Device running the TFTP server and the router. This will avoid timeouts occuring due to media sensing/media detection.
If you like, you can run a continuous ping or -even better than that- wireshark to monitor the progress of flashing. Otherwise just wait and watch the LEDs in the router’s front – if “Power” and “Sys” are lit soon after all lights flashed up for a second, it seems to habe worked. Just be patient.
Router conditions and starting positions
So there are different cases:
If you have an old TP-Link TL-WR1043NDv1 and flashed it right from the original firmware to DD-WRT, OpenWRT, Gargoyle, LEDE and all the others, your bootloader never got updated. If you run into a brick now, you will have to use the serial console to issue commands to trigger ethernet tftp-client operations. Therefore you have to carefully open the case and … it’s much work and very time consuming when you don’t plan to upgrade the board with a serial plug anyways…
Even when you reverted from *WRT to a currend version of the original firmware, it will not update the bootloader. The process to revert back as described on OpenWRT’s wiki consists of stipping of the bootloader before flashing only the kernel and the compressed rootfs via “mtd”.
In that case, you have an actual version of the original firmware, but you stick at an old bootloader version, not capable of a semi-automatically working recovery TFTP routine.
If you now flash to a *WRT and brick the router, again, you’d have to rely on the serial console method for debricking.
As pointed out, it is important to have the most actual bootloader from the original manufacterer’s firmware on the router before starting to migrate to any other firmware.
If your device appears to be already at the most recent version of the firmware (the web interface tell you about version 3.13.5 (140319), this does not need to be true for the bootloader as well.
To be sure, you could run wireshark and power up the router with reset pressed. If you see ARP-Requests for 192.168.0.86 (this is your router) and 192.168.0.66 (this will be your tftp server), the boot loader is ok.
If you dont see anything in wireshark, you probably have some problem with media detection or your ethernet device in the PC.
If you see something in wireshark, but no ARP requests as described above, you should flash the OEM’s firmware all over again. Go to “System Tools”, “Firmware upgrade” and flash “wr1043nv1_en_3_13_15_up_boot(140319).bin”. You can retrieve that from the TP-Link’s website.
When you’re done with that, try again to see, what wireshark tells you about ARP.
If ARP is fine, you now have good chances that you don’t need to open the case, if something goes extremely wrong flashing an alternative firmware.