The router worked. That is the part I keep coming back to. It sat on a shelf for two years, served DHCP, did not drop the WiFi, and asked nothing of me. So naturally I decided to reflash it.
In my defence the stock firmware was end of life. No more security updates, an ageing kernel, and a web UI that felt designed to discourage curiosity. OpenWrt supported the model. There was a wiki page, there were instructions, and the instructions even had a tick next to "fully working". I have been doing this long enough to know that a tick on a wiki is a statement of intent rather than a guarantee, but I chose to believe.
the easy bit, which is never the easy bit
The plan was the boring, safe one: flash through the stock web UI's firmware upload, let it write the OpenWrt sysupgrade image, reboot, done. Plenty of people do exactly this and never touch a soldering iron.
The stock UI rejected the image. Wrong magic bytes, it decided, and refused to proceed. This is a common defence: the vendor checks for their own header so you cannot accidentally flash something hostile. The OpenWrt page had a factory image specifically built to satisfy that check. I downloaded it, verified the sha256, uploaded it, watched the progress bar crawl to 100%, and then watched the router do nothing at all.
No lights in the usual pattern. No DHCP. No web UI on the old address or the new one. I had bricked it on the first attempt, through the officially supported method, with the correct image. Marvellous.
serial, because of course it came to serial
Every cheap router has a serial console somewhere on the board. It is usually four pads or a depopulated header: ground, transmit, receive, and a voltage pin you must never connect. Finding them is half guesswork and half cross-referencing photos from someone who did this before you and was kind enough to post the result.
I opened it up, found the four pads near the SoC, and went looking for ground with a multimeter against the shield. Then the unglamorous part: my pads were tinned but flat, and my hands are not as steady as they were, so I soldered a three-pin header on at an angle, bridged two pads, reflowed it, and tried again. The first sign of life is always the same little thrill, a wall of boot text scrolling past at 115200 baud:
U-Boot 1.1.4 (build date stripped)
DRAM: 64 MB
Flash: 16 MB
Hit any key to stop autoboot: 0
That Hit any key line is the whole reason serial is worth the bother. Interrupt the boot, drop into the bootloader, and you have a way back in that does not depend on whatever you just broke in flash.
tftp, the protocol that refuses to die
From U-Boot the recovery path is TFTP. The bootloader brings up its network stack, asks for a file from a fixed server address, writes it to flash, and boots. It is from a more trusting era of networking and it is wonderful precisely because it is so simple. No handshake worth mentioning, no auth, just "give me this file".
I set a static IP on my laptop, pointed a TFTP server at the recovery image, and typed the magic incantation at the U-Boot prompt to fetch and write it. The transfer ran. The erase ran. The write ran. And the thing booted, properly this time, into a working OpenWrt that brought up an interface and let me SSH in.
So why had the supported method bricked it? As best I can tell, the factory image expected a slightly different flash layout than the one my hardware revision actually shipped with. Same model number on the box, different board underneath, the oldest trick in consumer hardware. The web UI happily wrote the image to the wrong offset and the result was an expensive paperweight until serial bailed me out.
was it worth it
Honestly? On a strict cost-benefit basis, no. I spent an evening and a roll of solder rescuing a device I could have replaced for the price of a takeaway. The router that worked now works again, doing the same job, with newer software and a kernel that gets patched.
But that was never really the point. The value was the serial console and the U-Boot prompt, because now I know this class of device has a back door that belongs to me, not the vendor, and I know how to use it. The next time a wiki tick lies to me I will go straight for the header and skip the part where I pretend the safe method is safe.
A note for anyone tempted to follow: photograph the board before you touch it, write down the exact U-Boot environment variables before you change anything, and keep a known-good recovery image on the TFTP server before you flash, not after. The order matters. The whole genre of this hobby is making the irreversible reversible, and you only get to do that if you set the safety net up first.
Leave the working router alone. Or don't, and learn something. I never seem to manage the former.