Saturday, June 18, 2016

Flash the BIOS


Some years ago-never mind how long precisely-having little money in my purse, and nothing particular to interest me on shore, I thought I would set about to fix a friend's computer.  I can't recall what was actually wrong with it, but at some point, I figured I might try to flash the BIOS for no real reason.  The long story short is I used the wrong BIOS file and ruined the computer.

Since then "Flashing the BIOS" has become an inside joke.  That being said, I've learned a lot of lessons over the years, and would not make the same mistakes today.  As an example, let me regale you with this tale:

A New Router

I recently moved, and my best internet option here was xfinitywifi which is broadcast in the area.  However, I needed to be able to connect any device to that without going through their web portal, and be able to hook up wired devices.  Simple enough, I bought a router, and installed DD-WRT on it.  There was the potential for bricking the router, but I did my research and found a version of DD-WRT with numerous confirmed successful installs on the internet.

The install went fine, and as an added bonus, the antennas on my router picked up the xfinitywifi signal much better than my laptop.


All was well in the world.  But then my internet started going down.  It turns out my router would lock up and crash, and need to be restarted.  This seemed to be happening with increasing frequency.  The solution seemed obvious.  I bought a 120 V relay and wired it to a Raspberry Pi.  I then wrote some code to ping some sites to see if the internet was still up, and if not, to restart the router.  This was an iterative process, as I discovered the router would sometimes allow pings to IPs (like google's DNS, even in its frozen state.  I also noted that pings to the router would occasionally still work, even when the router refused to serve the status page.  So I changed the script to check the status page via wget.

This worked pretty well.  I set it up to run every 30 seconds, and to restart the router as soon as it couldn't get the status page.


Searching online though, it seemed like no one else was having this problem.  I figured this may just be because I was using the less common repeater mode, but it may have also been because I was using an older release of DD-WRT, since I wanted to find one with plenty of confirmation it wouldn't brick the router.  I found one or two people who said they were running the latest version on that router so I decided to upgrade the firmware to the newest version.

I carefully found the correct file, and plugged directly into the network so there was no chance of being disconnected during the update.  When I figured I was ready, I hit upgrade.  As soon as I clicked the button I realized my mistake.  My router was still hooked up to my crazy Raspberry Pi contraption.  Within the next 30 seconds the Pi would try to get the router status page, fail, and then cut the power to the router.

There was nothing I could do.  Pulling the plug on the Pi would cut the power to the relay and cause it to open.  My only chance was to SSH into the Pi and kill the process.  That, of course, relied on the network being up.  As soon I hit enter on the SSH command I heard the click of the relay turning off.

And with that, my router was bricked.

I tried a few recovery methods I found online, but it didn't matter.  My router had a half installed firmware, there was no way for it to boot, so it looped endlessly.


While connecting directly to xfinitywifi gave me some internet, it was unreliable and I wanted to get this resolved.  I convinced myself just to get a new router, one that would hopefully not have the freezing problem.  Walmart was the only place that was open so I found that they carried the Netgear Nighthawk router and set off to buy it.  I arrived at 12:01 am to discover that the Walmart I was at closed at midnight.  I drove to another Walmart to discover they didn't have any in stock (despite their site claiming they did).  I bought a lesser router, figuring it might be better than nothing.

A New Hope

When I got home I thought more about what to do with the broken router.  I, of course, considered switching out the guts, but I didn't have any of the packaging, and knew I couldn't just put the old router in a new box since the serials wouldn't match.

I did more research and discovered two more advanced recovery methods.   The first involved setting up a TFTP server, and connecting directly to the router, with a static IP that it would check for a certain file and then flash itself with.  I set this all up, and as luck would have it, it got the file from my computer and started to flash itself.  Then it rebooted, and rebooted.  I guess it didn't have enough firmware written to get through the firmware update steps before it rebooted.

A New Hope, Part 2

The more involved method, as these things so often do, required opening the router and soldering some pins onto the board.  While my new apartment is pretty barren, one thing it does not have a dearth of is random electrical components.  I had pin headers, male to female jumpers, even a USB to UART breakout board.  It was about 3 am at this point, which seemed like the ideal time to begin the next phase of this project.

I opened the router, found the through-holes, broke off three headers and placed them in the correct holes.  Hooked up Rx, Tx, and Ground to my UART, plugged that into my laptop, and attempted to connect via PuTTY, and got nothing.  It was pretty odd as I was sure the connections were right.  I have done USB serial communication stuff before though, and I know it's very easy to get the connection details wrong.  That being said, usually that would result in gibberish, not nothing.  After much experimentation I noted I could sometimes get gibberish if I moved the connections around.  This led me to believe perhaps the connections actually needed to be soldered, and not just placed there.

At this point, I feel it's worth noting that while I have a nice large table in my living room, I only get internet via my laptop in my bedroom.  I did buy a large corner desk for my room, but have yet to assemble yet, despite sitting around in my apartment every day with nothing to do.  As such, all this work was being done with me in bed with the parts in bed with me.


It was about 4am when I turned on the soldering iron (which I did do in the living room, not in bed).  I soldered the headers on, and as is tradition, discovered I soldered it wrong, so had to unsolder everything and redo it.  I hooked everything up, and still got nothing.  I suspected my router had so little firmware on it, that it couldn't even communicate over serial.  I checked and rechecked the connections, but there were only 3 wires.  Ground to ground, Rx to Rx, and Tx to Tx.  Then I realized, how could Rx connect to Rx?  Both sides can't be receiving.  Sure enough, the directions I was following clearly stated Rx to Tx.  At 4:45 am I fliped the Tx and Rx wires and immediately got communication.  As I said, I've done this USB serial communication before, and I made this same exact mistake before.

Flashing the firmware was a few simple commands, it grabbed the file from my TFTP server, via ethernet, and rebooted.  It worked fine.  I figured I might as well reflash it with the DD-WRT firmware while it was in this disassembled state.  That was done in a few minutes, and the router was reassembled (with pin header conveniently left soldered on for future endeavors) by about 5:15 am.  Just in time to watch the sun rise while browsing reddit.


  1. Thats the script for a modern day techno-thriller movie.

    The original failed flashed BIOS stemmed from that dual P2 motherboard. I think we couldnt get Win2k on it and that was deemed the culprit. In retrospect: if Windows drivers were a complete hassle until WinXP, there was a 0% chance a dual P2 BIOS would have been an achievable operation.

  2. Good read and technical evaluation from Todd.