About technologies for your digital home

For beginners and tinkerers

Bricked Router

April 23rd, 2014

What is bricked router (brick)?

Basically “bricked router” means an electronic device which is as useful as a brick 😉 In such case, the device may power on (some LEDs will turn on), however it will not function as intended by manufacturer:

  • your router does not work as it is supposed to
  • you are unable to even ping the device
    (in some cases, your router’s IP address might change to the default one)
  • you are unable connect either through web console or SSH (Telnet) protocol

If at least one of above conditions is met, then you have partly or fully bricked router. In my case, I tried unsuccessfully to flash my WNR2000v1 with OpenWRT and ended up with the bricked router:

Router Debricking Guide

But after reading ina few different places, I found a way how to recover the router and fix OpenWRT on it. This motivated me to write this post 😉

Why does it happen?

There can be many reasons for this. Here is a list of few major:

  • There was an attempt to flash a firmware and it failed
  • The wrong firmware was used for the update
  • You were tweaking the router with custom firmware like OpenWRT or DD-WRT, like in my case 😉

What to do next to recover?

1st rule – Don’t panic If you are stressed, I would suggest to take a break. Go and have nice a cup of warm tea or coffee 🙂 And by all means don’t flash everything you can find on Internet.

2nd rule – Try to understand the firmware structure and the boot process
I will briefly explain a basic routers firmware structure and how does the router boot. There are two main parts in whatever vendors router:

  • the bootloader (Adam2, CFE, PSPBoot and U-boot etc.)
  • the rest of the firmware (Linux Kernel and VxWorks etc.)

First, the bootloader starts and initialized CPU. After this phase, the flash configuration is read from the bootloader variables and if all flash parts are present, the bootloader loads the firmware image. During loading, the bootloader usually checks the CRC of the firmware. If everything matches, the router boots by loading the firmware from the flash chip. However, if the wrong firmware update was attempted: the CRC check would fail, a part of the flash will be filled with useless information. So the rooter can enter the initialization-reboot loop.

It’s important not to modify/damage the bootloader! Otherwise, the recovery can get quite complex including reprogramming the flash chip after re-soldering it or using JTAG interface.

1st bricked router recovery method

Until your router’s bootloader is OK, you should be able to access the vendor’s implemented TFTP or WEB recovery mode, which is part of the bootloader (however, not in all routers). How to access your specific router recovery mode, you may find on OpenWRT and DD-WRT websites, including their forums.

E.g. in order to access TFTP mode on Netgear WNR2000v1, you have to follow such steps:

  • power off the router
  • keep pressing a reset button
  • switch on the router ~30sec.
  • after the power LED starts to flash in green, release the button
  • your router is in TFTP recovery mode 🙂

The next thing which you will need is a TFTP server on the same network as your bricked router and the original firmware, which you can get on the vendor’s support website. On Windows, you could setup this freeware TFTP server and use it to push the firmware using TFTP protocol to your router. On Linux, you can just issue the equivalent command:

tftp -i put wnr2000v1.bin
and after few minutes your router should be alive and back 😉
That helped me to recover my Netgear WNR2000v1.

What to do if TFTP method does not work?
2nd recovery method

Well, … things sometimes get more complicated. It might be, that during for example failed firmware update process some other firmware parts were damaged/modified (e.g. the bootloader) or just the TFTP mode was not enabled by the vendor in the bootloader. In such cases, the diagnostics need to be done in order to understand, what is happening with your router.

For this purpose, you need a serial console on the router and an USB-serial console cable. Dependent on the router, you may find it’s serial port already soldered, e.g. Netgear WNR2000v1 or you will have to solder yourself.

Keep in mind, that the router’s serial port voltage is different (3.3V) from the standard serial port. So, a converter is needed. I made an USB-serial cable from a non-genuine CA42 cable which I got from eBay:

Router Debricking Guide

If you are going to use such one, remember that usually they have non-original chip inside (not a Profilic PL2303) and you can experience some troubles in getting it working in Windows. Here you can find drivers which worked for me with the non-genuine PL-2303 chip. The cable was detected without any problems in Linux 😉

You could check the OpenWRT website for the router’s serial port settings and use them. You can use this hyper terminal on Windows as terminal program, which I found on Internet. ‘cu’ or ‘screen’ commands as terminal programs can be used on Ubuntu.

After connecting to your router, you can see all router’s messages and what’s happening. E.g. your router does not find part of the firmware, it enters the reboot loop or other errors. This will help you decide what you should next in order to recover the router.

Recovery using serial console and (or) Ethernet port

So the serial console is quite useful and not only for seeing the router’s messages but also for uploading the firmware. Either the serial port (even if the transfer speed reaches only 115kbps) could be used for the recovery or the Ethernet port would be used to get the firmware from your TFTP server in the bootloader environment.

In order to enter the bootloader environment, you have to break the booting procedure, which depends on the router. In my case, that was just pressing ‘4’ during the boot process.

The U-Boot environment helped me to replace some parts (e.g. ubootenv-stockpartitions.img) of OpenWRT firmware over the serial port by issuing the commands on my WNR2000v1:

## Ready for binary (ymodem) download to 0xA0800000 at 115200 bps...       C

After this, the terminal program hypertm was opened and the image ‘ubootenv-stockpartitions.img’ was uploaded through the serial port into the router’s memory.

Later, the commands were issued in the bootloader U-Boot environment to erase a part (nor0,1) of the flash memory and copy the uploaded image :

erase nor0,1 or erase 0xbf040000 +0x10000 
cp.b 0x81000000 0xbf040000 0x10000

After this, my router got the fixed OpenWRT parts and it is used as a wireless repeater in our attic.

How to recover without the serial console?

There are two last recovery methods. That are JTAG and reprogram a flash chip. However, they are more complex compared to the previously described and soldering is involved in both of them.

This OpenWRT guide is a good starting point for reading about the JTAG interface.

The 2nd method is to de-solder the flash chip and reprogram it using the official firmware. You would need some flash chip programmer (e.g. USB based) or you can build one using the Raspberry Pi. I used it once for a similar purpose for the BIOS recovery with the SPI flash chip. But that is another story 😉

I hope that you got the ideas on where to start and how to recover your (potentially) bricked router.