Ramblings of an aging IT geek
← Ramblings of an aging IT geek
hardware

i reflashed a router that was working perfectly well

A perfectly functional home router gets flashed to OpenWrt for no good reason, briefly becomes a brick, and is rescued by a serial console and a TFTP recovery that the manufacturer never documented.

A router opened up on a desk with a USB serial adapter clipped to header pins

The router worked. I want to be clear about that up front, because everything that follows is my own fault. It routed packets, it served DHCP, the wifi reached the bottom of the garden. There was no problem. There was only the stock firmware's web interface, which I disliked on principle, and a vague itch to put OpenWrt on it so I could have VLANs I would never use and a cron table on my front door.

The flash itself went fine, which was the trap. The web UI accepted the factory image, rebooted, and came up dark. No lights doing anything reassuring, no DHCP, no ping. I had a brick the colour of a working router.

A bricked router with only the power LED lit, refusing to negotiate a link

The mistake was not reading the device page carefully enough. This particular model has two hardware revisions that look identical and take different images, and I had, with the confidence of a man who has done this before, flashed the wrong one. The bootloader survived (they usually do, that's the point of them) but the firmware partition was now full of an OS the SoC could not run.

Out came the screwdriver and the USB-to-TTL adapter that lives in a drawer for exactly these evenings. Three header pads on the board, unpopulated but clearly labelled if you squint: ground, TX, RX. I left the 3.3V pin well alone, because feeding voltage in from the adapter while the board has its own supply is how you turn one dead router into two. Solder on three flying leads, screen /dev/ttyUSB0 115200, power on, and there it was: U-Boot, spilling its startup chatter into the terminal like nothing was wrong at all.

U-Boot 1.1.4 ...
Hit any key to stop autoboot:  3

I hit a key. The thing every cheap router's bootloader gives you, if you can only reach it, is a TFTP recovery: hold it at the prompt, point it at a TFTP server on your laptop, and let it pull a known-good image directly into flash, bypassing the broken OS entirely.

ar7240> setenv ipaddr 192.168.1.1
ar7240> setenv serverip 192.168.1.2
ar7240> tftpboot 0x80060000 openwrt-correct-revision.bin
ar7240> erase 0x9f020000 +0x3c0000
ar7240> cp.b 0x80060000 0x9f020000 0x3c0000
ar7240> bootm 0x9f020000

The correct image this time, the right revision, checked twice. It pulled, it erased, it copied, it booted, and the lights came back in the order that means a router is happy. Total downtime, about ninety minutes, most of it spent finding the adapter and resoldering one lead I'd done badly.

So: it works now, it runs OpenWrt, it has VLANs I am not using and a cron table on my front door, exactly as planned. Was it worth it? No. The thing already worked. But I'd argue the serial console was worth it, because the real outcome of the evening was not the firmware. It was confirming that a router is only ever as bricked as your access to its bootloader, and that three solder pads and a two-pound adapter turn "dead" into "inconvenienced". I'll still leave the next working one alone. Probably.