Ever had a piece of hardware that didn't work quite right because the firmware had some minor flaws? It happens all the time. Thankfully fixes always arrive in the form of nerve racking firmware updates.

This story, like many others, starts with what seems like a simple solution to a problem. Before you know it it's 4am the next day and all you care about is if a particular blink LED blink pattern shows up on your device to tell you it's still alive and not bricked.

Before we get into the details, a little context. After getting my Nexus One (AT&T version), I noticed I always had problems downloading large files over WiFi on an encrypted network. You can see my desperate beg for help on a local developers group (http://librelist.com/browser/ottawaandroid/2011/2/14/nexus-one-wifi-issues/). Sadly, I still don't have the problem resolved. After talking to another developer at a meeting with the same problem it seems like the thing we had in common is dual band wireless routers (2.4GHz/5GHz for A/B/G/N). With no actual testing or open source versions of the broadcom drivers for the WiFi chip in the Nexus One (or for the router), we shall never really know.

Anyway, the one work around that seems to work reasonably well for me is to use gasp an unsecured network. Hey, before you judge place yourself in my shoes. The 3G data plans are terribly overpriced for the data limits you get and I download audio podcasts about 30~40mb in size x 7~8 a week... you get the idea why I want to use WiFi. An unsecured network to download these doesn't seem that bad.

So I devise a plan. I installed the open source alternative router firmaware called dd-wrt. One of the cool thing you can do is create virtual interfaces for more networks. So I have my regular "Secure_2.4GHz" network and my "Nexus_2.4GHz" all running off the same router and the same radio. The best part is that you can have different encryption schemes on the different networks.

So after creating my virtual unsecured and isolated "Nexus" network, I can download my podcasts. For security reasons I disable the "Nexus" network when I don't need it. Here lies the problem: enabling/disabling the virtual interfaces seems to lock up the radio requiring a router reboot. It's not a big deal, but enough to annoy you after a few times. I decided to try my luck with a newer SVN build of dd-wrt hopping it might fix this flaky virtual interface issue (11:30pm).

I followed the simple instructions to upgrade dd-wrt on my Netgear WNDR3700 router to the latest SVN firmware build. Next thing I know my router is no longer accessible. A quick internet search (thanks to the tethering on my phone), I figure out that I had a bad firmware flash. After eventually reading more guides I finally give up on trying to reset the router and resort to following the instructions to reflash the stock firmware using tftp.

I successfully get the stock firmware back on the router (2am). I got used to dd-wrt, so I want it on my router again. "I successfully installed dd-wrt on my router from stock once, I can do it again" I told myself. Luck was not on my side. I was back to square one. A half bricked router. Apparently the SVN build I was trying to install was know to have flashing issues. Knowing this ahead of time would have saved me a lot of trouble.

After browsing the forums and finding an SVN version known to be good I proceed to flash that version. The problem now is that my router was in an infinite reboot cycle. The method I used before wouldn't work. I thought I had just bricked my router now.

After spending another hour, trying various things, hoping to get the "magical" LED blinking pattern (signifying the short window in which the router looks for a tftp server) I finally got it into a "flashable" state. I flashed the known working version of dd-wrt onto the router. Reconfigured all my setting ad went to bed at 4am.

So the lesson is:

  1. the latest firmware might create more problems than it fixes
  2. flashing new firmware can be risky business, be prepared to face the consequences of a bad flash (hours spent fixing/new hardware)

I tip my hat off to all the embedded firmware developers out there.