The router worked. I want to be clear about that before anything else, because it is the load-bearing fact of the whole story. It had worked for two years, it was doing nothing wrong, and I decided, on a quiet Tuesday evening with nothing else demanding my attention, to flash it with a newer build of OpenWrt. Not because anything needed fixing. Because it was there, and because I had read the changelog, and because I am, apparently, incapable of leaving a working thing alone.
You can see where this is going. The fun part is how, and what it took to undo.
The flash that went quiet
The web flash started normally. Progress bar, the usual stern warning about not removing power, the reassuring hum of a device rewriting itself. Then the progress bar stopped at something like eighty percent and stayed there. After a polite interval, then an impolite one, then long enough that I had made tea and come back, it was clear it was not going to finish.
The honest mistake underneath the obvious one: I had grabbed the generic build for the chipset rather than the specific build for this exact board revision. They are close enough that the flash starts and not close enough that it works, which is the worst possible combination. Close enough to begin, wrong enough to fail halfway, and halfway through writing a flash chip is precisely where you do not want to stop.
I power-cycled it, which is the universal first instinct and, here, the universal second mistake. No lights settling into their usual pattern. No web interface. No DHCP lease handed out, no response to a ping at the default address, nothing on any of the addresses it might plausibly have fallen back to. A brick. A small, beige, formerly-useful brick.
Where the recovery actually lives
Here is the thing the consumer-router world hides from you: almost all of these boxes have a serial console on the board, a handful of unpopulated pads or pins that speak to the bootloader directly. The bootloader is a separate, smaller piece of software from the firmware, and crucially I had not touched it. It was sitting there, intact, waiting to talk to anyone who could reach it, which from the network was nobody and from the serial header was me, if I was willing to get the iron out.
So I opened it up. Four pads in a row, the classic giveaway. A multimeter and a bit of squinting sorted out which was ground, which was transmit, which was receive, and which was the 3.3V I very much did not want to connect to my adaptor. I soldered a short header on, wired up a USB-to-serial adaptor at the usual 115200 baud, and opened a terminal.
screen /dev/ttyUSB0 115200
Power on, and the screen filled with boot messages. That moment is genuinely a relief, because boot output means the bootloader lives, and a living bootloader means the box is recoverable rather than landfill. It got partway into trying to boot the broken firmware, failed, and dropped, after a bit of prompting, to a bootloader prompt.
TFTP, the unglamorous hero
From the bootloader I could do the one thing the web interface no longer could: pull a known-good image over the network and write it directly. The bootloader speaks TFTP, so I stood up a TFTP server on the laptop, put the correct board-specific image where it could find it, set the relevant addresses, and told the bootloader to fetch and flash.
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.2
tftpboot 0x80060000 openwrt-correct-image.bin
This time it pulled the right image, wrote it cleanly, and rebooted into a working system. The whole recovery, soldering included, took about two hours, of which roughly ninety minutes was me being careful with the iron and ten was the actual flash.
What I actually learned
Three things stuck, and only one of them is technical. The technical one is that the bootloader is your lifeline and you should know how to reach it before you need to, not after. A serial console turns a brick back into a router; without it that box was bin material. If you flash custom firmware on anything, find out where its serial header is whilst the device still works, because hunting for it on a dead board with no documentation is a worse evening than this was.
The second is that "generic for the chipset" and "specific for the board" are not the same image, and the few minutes it takes to confirm you have the exact right build are the cheapest insurance you will ever buy.
The third is the one I keep failing to internalise: a working system is a feature. The urge to improve a thing that is already doing its job has cost me more evenings than any actual fault ever has. The router did not need flashing. I needed something to do, and I dressed it up as maintenance. Next time the changelog looks tempting and the device is working fine, I would like to think I will leave it alone. I would not bet the soldering iron on it.