De-bricking a soft-bricked router

So today I managed to soft-brick my router … I hadn’t done that in a while. The repair process is fairly simple, but is a huge pain in the ass. Why? because it involves tftp (trivial file transfer protocol) and a whole lot of timing so be patient.

Now keep in mind that depending on the brand, age, and model of your router you may have to perform these tasks in a slightly different manner, but the gist is the same. I’ll keep the instructions generic.

 

Disclaimer

This is only a guide. I’m only showing you the door, you’re one who walks through it. If you break your device following these instructions, it is you who broke it. Blame me and I’ll laugh at you. Generally if you don’t understand clearly the instructions you’re following, you’re asking for trouble.

Connect

If your router is soft-bricked or has a problem that prevents you from getting to the GUI, there’s a good chance that the DHCP server (the thing that assigns an IP addresss to the client) isn’t running. Even if it is, it won’t be running during your window of opportunity. You ideally know the IP address of your router (this is the one you set in the ‘LAN’ section of the set up). If you know your device’s IP address (let’s say 192.168.1.234), then your router most likely has the same first 3 numbers. A few safe bets for the 4th number would be 1, 254, and 253 (in that order). Keep in mind that the individual numbers making your IP address are from 0 to 255 and that 0 and 255 are reserved. You may be able to ping with 255 as the last number (broadcast) and see if the router responds. For example, notice below that although I pinged 192.168.1.255, I received a response from 192.168.1.33. For security reasons, most devices will not respond to broadcast pings, but your router may while the bootloader is running.

[email protected]:~$ ping -b 192.168.1.255
WARNING: pinging broadcast address
PING 192.168.1.255 (192.168.1.255) 56(84) bytes of data.
64 bytes from 192.168.1.33: icmp_seq=1 ttl=64 time=0.777 ms
64 bytes from 192.168.1.33: icmp_seq=1 ttl=64 time=149 ms (DUP!)

I really don’t have a guaranteed way of knowing the router IP. In my case I already knew this IP.

Once you have the router IP, you’ll need to put your network connection in manual mode. You need two things: the router IP and another IP on the same subnet (first 3 numbers match). Using the above numbers, the router IP is 192.168.1.1 and your IP is 192.168.1.234 (the subnet address is 192.168.1.0). In Windows, you’re setting your IP(v4) connection type to static and in Linux it’s called manual mode. Set your IP address to 192.168.1.234 and the gateway IP to 192.168.1.1 (this is all on your computer, you can’t access anything in the router, in case you forgot).

Check for a pulse

Before you waste your time with a dead router, make sure there’s a pulse! In my case, the router was stuck in a reboot loop. The easiest way to do this is to ping it continuously (Linux: just use ping. Windows: use ping -t). You’ll see one of the cases below. Keep in mind that the output below is simulated and much shorter than what you’ll see. Your ping replies will not all have the same time. The duration in which you receive ping replies is much larger than below and so is the duration of the Destination Host Unreachable phase.

Bootloader reboot loop

In this case, the router starts to boot, but the bootloader forced to reboot (possibly due to a corrupted firmware image). You have a duration in which the router is responsive and a down time.

[email protected]:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=100 time=0.777 ms
Destination Host Unreachable
Destination Host Unreachable
Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_seq=7 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=100 time=0.777 ms

Firmware reboot loop

In this case, the router starts to boot and the bootloader is able to start the firmware, but the firmware is forced to reboot (possibly due to a corrupted, missing, or invalid configuration). You have a duration in which the router is responsive and a down time. Can you tell which ping replies below are from the firmware?

[email protected]:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.777 ms
Destination Host Unreachable
Destination Host Unreachable
Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_seq=9 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=100 time=0.777 ms

The ping replies with ttl=100 are from the bootloader and those with ttl=64 are from the firmware.

Frozen

In this mode, the firmware starts, but freezes shortly after starting (possibly due to invalid/corrupt/missing configuration or hardware). What you see is a period of responsiveness from the bootloader, followed by a period of responsiveness from the firmware, and then darkness falls.

[email protected]:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=100 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.777 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.777 ms
Destination Host Unreachable
Destination Host Unreachable
Destination Host Unreachable

At this point if you’re sure you’ve got the router IP address right and still can’t get a ping response, well … NO SOUP FOR YOU!

The Firmware

Now that you know you can recover, you need to get the latest firmware for your router. You can find the firmware on the manufacturer’s support site under downloads (or drivers, although it’s not a driver). If you’ve downloaded an archive (zip, tar, tgz, tbz, …), you have to extract the firmware file from the archive. There should only be one file in the archive (ignoring any readme, license, legal, or that kind of junk). The firmware file often has a bin or trx extension (e.g. oem_model_rev_version_.trx).

TFTP Client

In order to initiate the recovery, you’ll need a TFPT client so go get one (hint: sudo apt-get install tftp). Google it. I’ll wait.

Operation: de-brick

Looks like you have everything in order. Let’s get started. Remember those ping replies with ttl=100? Let’s call those your window of opportunity (WoO) as they roughly represent the duration in which the tftp server is available and waiting. Keep in mind that regardless of which pattern (above) your router is displaying, your window of opportunity is limited and it often closes fast. You have to initiate the transfer during this time.

  1. Open 2 shell/cmd windows
  2. In one window start pining the router (Win: ping -t 192.168.1.1 or Linux ping 192.168.1.1). What you’re doing here is finding your WoO.
  3. In the other window have tftp ready and the name of the firmware file in your copy+paste buffer
  4. Once you see your WoO, you want to push the firmware file to the router. This really depends on the TFTP client you’re using. Generally you want to set the host to 192.168.1.1, the transfer mode to binary, and set the retries to a high count, say … 99? The commands below should work for your standard commandline tftp client
[email protected]:~$ tftp 192.168.1.1
binary
put oem_model_rev_version_.trx

This’ll take a while depending on the size of the firmware and connection speed, but trust me it’s worth the wait! If you miss your WoO, try try try again. You pretty much want a success message that normally states how many bytes were transferred and how long it took. If you interrupt the process, you have to start over.

Once the transfer is over, the device will either automatically reboot and you’ll have to manually reboot it. Make sure the transfer is finished before you reboot. Keep the pings running as they can be your early indication of success (you’re looking for ttl=100, changing over to ttl=64 and the device continues to respond).

Once the device finishes booting, give it a good factory reset. You may also want to do a 30-30-30 reset to clear nvram and get rid of anything that possible caused it to misbehave the first time. Of course if the problem had hardware origins it will come back sooner or later.

30-30-30

Not all routers support this, but the worst that could happen is that you waste 90 seconds. Push and hold the reset button on the router and do not let go until I tell you. Wait 30 seconds and unplug the power from the router. With the router off, wait another 30 seconds. You’re still holding the reset button, right? Good. Keep at it. Now plug the router back in. Wait another 30 seconds. Now let go of the reset button. If at any point during this time you let go of the reset button, you screwed up. Do it again.

That’s it!

My router works now, hope yours does too!