The router worked. That's the part I'd like on the record before I tell you the rest. It sat in the corner, did its job, routed my packets, never complained. And on Boxing Day, full of leftover ham and a dangerous amount of free time, I decided it would be improved by replacing its perfectly functional stock firmware with OpenWrt. Reader, it was not improved. For about four hours it was a paperweight with a sad red light.
This is a familiar genre of mistake for me. The thing is fine, I have an afternoon, and "fine" starts to feel like "untapped potential." It is not untapped potential. It is a working router.
why i thought this was a good idea
The honest answer is the stock firmware was getting no updates and the device had four times the RAM the manufacturer's web UI ever used. With OpenWrt I'd get a proper package manager, real iptables control, SQM for the upload my ISP keeps strangling, and the ability to actually see what the network was doing. All true. All still true. None of it required doing the flash at half nine at night without reading the device-specific notes first.
I did the responsible-looking things. I checked the table of hardware, confirmed the model and the board revision, downloaded the right factory image. What I didn't do was check that my specific hardware revision had a known issue with the web-UI flash on stock firmware, where the upload completes, reports success, and writes a truncated image. Which is precisely what happened.
the brick
After the "upgrade," the router rebooted into nothing. Power LED solid, no DHCP, no web UI on the usual address, no response to a ping at the recovery IP. The classic three-LED salute of a half-written flash.
I tried the obvious recovery paths first. The 30-30-30 reset, holding the button through a power cycle. Nothing. Some of these boards expose a TFTP recovery window in the bootloader if you hold reset on power-up and have a static IP on the right subnet, so I sat there with tftp queued up, mashing the button, watching tcpdump for any sign the bootloader was listening:
tcpdump -i eth0 -n port 69
Silence. Whatever boot stub was left wasn't bringing up the network at all, which meant the recovery I needed was a layer lower than the network stack. Time for the soldering iron.
serial to the rescue
Most of these consumer boards have an unpopulated UART header somewhere near the SoC, four holes labelled something like VCC, GND, TX, RX, or not labelled at all and left as an exercise. I found the pads, declined to connect VCC (you do not want your USB adapter fighting the board's own 3.3V rail), and soldered leads to GND, TX and RX. A cheap USB-to-TTL adapter on the other end, 115200 baud, and screen:
screen /dev/ttyUSB0 115200
The reward for all that soldering was a wall of U-Boot output scrolling past as the board powered on. The bootloader was alive and well. It was only the main firmware partition that was mangled. That is the best possible kind of brick, because U-Boot gives you a command line and a TFTP client, and from there you can write a known-good image straight to flash without trusting whatever broke last time.
I interrupted the autoboot, set the bootloader's IP and my server's IP, and pulled a fresh, verified image over TFTP:
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.10
tftpboot 0x80060000 openwrt-factory.bin
Then the slightly heart-in-mouth part, erasing the firmware region and writing the new image to it by hand. I checked the flash layout three times, because getting an address wrong here doesn't brick the router, it bricks the bootloader, and then you're into JTAG and a much worse evening. The numbers matched the board's documented partition map, so I committed, watched the erase, watched the write, and rebooted.
It came up. OpenWrt's LuCI greeted me on the first try, the network came back, and the house had internet again before anyone noticed it had gone. I sat there feeling enormously clever, which is the wrong feeling, because the clever thing would have been to leave the working router alone.
what i'd tell past me
Three things, and I'll spare you the tidy list and just say them. First, before you flash anything, find the recovery path and confirm it works before you need it. Knowing the serial header is there and tested turns a brick into a twenty-minute job. Second, never trust a web-UI flash on hardware with known quirks; if there's a way to write the image from the bootloader, prefer it. Third, and this is the real one, "it works but could be better" is not a fault report. It's an invitation to break something on a quiet afternoon, and sometimes I should just decline the invitation and have another mince pie.
The router is genuinely better now. SQM has tamed the bufferbloat, I can see every device on the network, and I get security updates again. I just want it understood that the four hours in the middle were entirely self-inflicted, and I'd do it again.