De-Bricking a Buffalo WiFi Router with an Arduino

My wireless router (Buffalo WZR-D1800H) failed the other day, when an apparent firmware bug caused it to go into a continuous reboot cycle. After going through the various reset options it seemed like it had been turned into an expensive plastic brick. Luckily there was a last resort method to gain debug access, see what was going on and hopefully bring it back to life. Internally there is a basic serial port, you just have to crack open the case and connect it to a PC somehow. However the serial port is not a usual RS232 standard, but a simplified TTY variant used more commonly for hardware debugging and firmware updates. That was the theory, next was to try it out…

Opening The Case

The pictures below are from the DD-WRT forum post by “Magnetron1.1 which shows how to open the case: Tools Opening 1Opening 2  Opening 3 Jumper

Connecting to a PC via an Arduino

After realizing I couldn’t just hook this up to my PC via an USB to serial (RS232) adapter, before giving-up and ordering a USB to TTY adapter, I stumbled upon this Electrical Engineering blog post that suggested my Arduino could do the same job. This was confirmed directly on the Arduino forum as being a valid configuration (that wouldn’t break my Arduino). Here’s how it looks when it is connected properly (using the “tri-state reset method” from the Arduino forum): Hardware 1 Hardware 2 Hardware 3 Hardware 4 Hardware 5 Hardware 6 Hardware 7 Hardware 8 Hardware 9 Hardware 10 First of all I only had the router->Arduino TX->RX and RX->TX connections and the Arduino Reset->Ground. But I was getting corrupt messages on the serial console of the PC. To correct this I found a few things were necessary:

  1. The baud rate must match the router and there is no flow control so they must be in sync. Setting the port speed to 115200 fixed most of the corruption.
  2. The ground cable totally eliminated the rest of the corruption of the messages coming back from the router (black cable in photo above).
  3. Although the output (received data) was now perfect, I still had to hit each key more than once to get it to go through. That maybe something to do with my serial console program or other buffer settings. But since I only wanted to issue some simple commands I just put-up with it.

At this point I could see the problem, “broken firmware”, followed by a reboot:

Serial 1 Failed Boot

Fixing The Router

The DD-WRT firmware start-up sequence will temporarily start with an IP address of (regardless of your configuration) then check for the auto-pair (“AOSS”) button press. When pressed it will attempt to download a file called “firmware.ram” from via TFTP. So you setup a free TFTPD server, download and rename the firmware you want to try. I did that, it downloaded, but failed to start. Not good… As the last resort, there is a command line you can use to fix it. To get into it you have to hit CTRL+C and hold it during the reboot:

Serial 2 Break

This breaks you into the “CFE” boot loader command line. The next step is to issue some commands to clear the non-volatile RAM (NVRAM) then reload the flash from the downloaded copy. But this failed as there was some issue with the download mechanism or format of the internal storage:

Serial 3 Auto Flash Download Fail

After a lot of searching through a sparsely documented command system, I worked out a command to download the same firmware again from my TFTP server. I wanted to see what the “timeout” was about (because all timeout settings were correct on the server). And to my amazement this forced download fixed the problem: flash -noheader -size= nflash1.trx

Serial 4 Manual Flash Download Success

After that I was able to get to the default HTTP configuration page at the default user IP address of and reconfigure my router. It works fine now.


Forcing a manual download with the “size” parameter specified worked around the failure of the “automatic” firmware recovery download. There must be some bug in the boot loader with auto-download, perhaps not flushing a download buffer or something like that. I still think DD-WRT and open source router/devices are great, but I’d recommend sticking to the older/stable firmware. If anyone can see why the serial input (keyboard) was out of sync (having to hit each key more than once) even though the output (received data) was perfect, please tell me! Maybe it should be cabled differently or different settings are required? I plan to look into the TTY standard more closely sometime. One thing I avoided was connecting the 3.3v power pin, because according to the Arduino forum that’s the most common way to damage an Arduino. 2014.04.21 UPDATE: I recently found the following article which has CTS and RTS connected to the 5V and RESET instead of a loopback jumper; perhaps that’s the synchronization fix? Needs further experimentation…

References & Acknowledgements

Thanks to “Magnetron1.1” on the DD-WRT forum for providing the information to help me fix my router. Visit the DD-WRT organization web site to download custom software for your compatible router! Thanks to Arduino for making such a universal device!

6 thoughts on “De-Bricking a Buffalo WiFi Router with an Arduino”

    1. The “firmware.ram” is the flash image file you download from the DD-WRT router database, placed into the folder where your TFTP server is sharing, renamed to “firmware.ram” (make sure you tell Windows to show file extensions else you may not be renaming the whole filename).

      You need to get hold of a free TFTP server/”daemon” in order to share the file. During boot/recovery mode the router acts like a client, downloading the file from your server, not the other way around. You should choose any known good image, because once you get the standard web administration GUI running of your router you try other images easily.

      I had success with TFTP Terminal. It didn’t require any special configuration besides choosing where the TFTPD server’s directory should be located (where you put the “firmware.ram” file). I tried some others suggested on the forums but they didn’t work for me, either were not found by the router or would start the download then hang.

      One last thing, be sure to choose an image which is not compressed. According to the forum post I linked to (where the first disassembly images were posted from) the boot loader does not support compressed images. You only know if they are compressed by checking out the forum. It appears some of the earlier DD-WRT images were compressed, then later images change to uncompressed. Try the latest stable release first then move forwards until you get some success, failing that ask the forum. Good luck!

  1. Hi There,

    Thanks for this awesome tutorial, I have the same issue you had and have the same setup to workaround, however I get the message that it was unable to load the firmware because it is not an ELF file?
    Also with the arduino as interface i don’t seem to be able to issue typed commands properly? as in I type but only some of the letters are input to the CFE?

    Any help appreciated.

    Thanks 🙂

    1. Probably too late now but here’s some random thoughts…

      1) Regarding acceptability of the downloaded file I can only think of two things which affect that. First that some firmware versions are compressed or not compressed (see the DD-WRT forum about which ones). Second that you must get the byte size parameter correct.

      2) The Arduino USB serial adapter trick is just a hack and seems to suffer flow control issues (because there is none). Even with the correct baud settings I had to hit keys several times before they got through. At least we seem to receive text in a way we can read the messages (when the ground cable is connected and baud setting correct) and enter some kind of emergency commands (frustratingly smashing keys multiple times) 😎 Best solution is a proper USB to serial adapter of course. I only used the Arduino because I didn’t have one at the time and couldn’t wait (no internet with bricked router). Would recommend one or two different types (5v, 3.3v, TTY, RS232, pin-out or FTDI header) as standard kit in a tinkerer’s toolbox 🙂

      Funnily enough just did a quick search on “FTDI Header” and found this…

  2. I’ve been working on de-bricking my WZR-D1800H for the past few days using your method, and I seem to be getting closer and closer, but I simply cannot do it and would greatly appreciate it if you would take a look at what I’m doing.

    I can communicate with CFE via a serial console (I have the same typing problem you did through an Arduino Uno), but I appear to be getting a different message. The last twenty lines of the console are as follows:

    TCP: veno registered
    TCP: scalable registered
    TCP: lp registered
    TCP: yeah registered
    TCP: illinois registered
    NET: Registered protocol family 17
    Bridge firewalling registered
    8021q: 802.1Q VLAN Support v1.8
    startup nvram driver
    found nvram
    found cfe nvram
    VFS: Cannot open root device “1f06” or unknown-block(31,6): error -6
    Please append a correct “root=” boot option; here are the available partitions:
    1f00 512 mtdblock0 (driver?)
    1f01 64 mtdblock1 (driver?)
    1f02 64 mtdblock2 (driver?)
    1f03 130048 mtdblock3 (driver?)
    1f04 131072 mtdblock4 (driver?)
    Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(31,6)
    Rebooting in 3 seconds..

    I’m very unfamiliar with this and am not really sure what to do, so I just went on with your instructions. I tried the command you gave it, but it timed out almost immediately. I set my IP address in windows to and the gateway to / 24. I used TFTP Terminal as you suggested in the above comment, and noticed that in the “Transfer” window is populated with blocked firmware.ram transfers from to (This sounds backwards to me.) Here is a screenshot:

    At this point I really do not know what to do. If you’re able to help me get this working I’d be happy to donate to the site for saving me from buying a new router.

    1. So the IP connectivity from the router is okay if it gets as far as printing the “blocked” message. I wonder if this is the router blocking the TFTP server/program or the TFTP server rejecting the request. Either way I would check all the program settings to make sure everything to do with transfer modes look sensible.

      Unfortunately I didn’t get around to include a full description of my example with a specific generally available TFTP program (TFT Terminal seems to have disappeared) including screen shots. If I do it again I will certainly add that here.

      If there was no blocked message on the router it must be something in the program or it’s access to the system. Try checking permissions (current user running program has write access without being member of local Administrator group) or run as administrator, try a different simple working path (C:\TFTP with Users granted full control). Clutching at straws really, looking for program debug messages or log files and any documentation of what “blocked” really means is the only way to properly diagnose it. But I fear this program is end of life so might have to give up on that one…

      Last resort can only be to try a different terminal program (took many until I got it working) and ask for help on the DD-WRT forum directly. This is their area and they should be able to help if you already got past the main hurdle of being able to connect to the thing via serial and default IP.

      Finally when you do get a transfer underway make sure the byte size parameter is correctly specified, i.e. as seen when opening the file properties in Windows, not the summary kilobytes or megabytes value you typically see in the main explorer views.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s