Recovering from a bad flash
Occasionally, a flashing attempt goes bad, leaving the router "bricked" -- that is, the router seems to be starting up, but otherwise doesn't provide network access and management pages are unreachable. Another common symptom: The power light on the front panel of the router flashes nonstop.
Fortunately, a flash problem is rare, and there are ways to recover from it. First, try a hard reset, or a "30/30/30" as the DD-WRT folks (and others) call it:
- Disconnect the router from the network and hold the hardware reset button for 30 seconds.
- Keep the reset button held down and remove the power cord for 30 seconds.
- Plug the power back in and keep holding reset for 30 seconds.
- Let go of the reset button and unplug the power one last time for a minute or so. Restore power.
This resets the router to its factory default state, which is sometimes needed to get it to boot properly after a flash. If that doesn't work, then you'll need to look into one of the more advanced recovery procedures listed on the DD-WRT and OpenWrt wikis. These include recovery via the aforementioned TFTP or JTAG. A truly wizardly hacker might add his own boot logic (such as Micro Redboot) to this mix, especially if he plans on trying out a variety of different firmware options.
DD-WRT and OpenWrt extras
A full breakdown of the most immediately useful features in DD-WRT or OpenWrt would require a book -- and might be redundant, considering many of those features are common to most routers. However, here's a sampling of features included with DD-WRT and OpenWrt that might not be present on other routers.
- Boot wait. When enabled, the router pauses for five seconds at boot time to allow the user to connect remotely and flash a new firmware if the current one is bricked. Leave this on, as you never know when it will be useful -- and what's five measly seconds out of a reboot cycle?
- Logging. DD-WRT and OpenWrt can maintain running logs of its most crucial events and behaviors. The log can either be kept locally or written to a remote IP address that has a syslog daemon listening on the appropriate port. This can be left off by default, but it's useful to toggle it on if you need to do any detailed troubleshooting (for instance, to find out if a specific action is messing up operations).
- Overclocking. Some routers support the ability to overclock, or run the CPU faster than the manufacturer normally recommends. There are few cases where this is a good idea, especially since overclocking any hardware often leads to instability.
- Scheduled reboot. You can force the router to reset itself at a given time of day, after a certain interval, or on a specific day of the week. Some claim this improves performance, although in my own experience it doesn't seem to make much difference. The documentation (linked above) shows you how to do this via a command line, but some builds -- including the one in my Buffalo router -- let you set this in the GUI under Administration/Keep Alive. Note that in order to use this, you'll need to enable the Cron option as well.
- Telnet. The telnet daemon should be running if you plan on connecting via telnet to perform administration (such as to manually flash new firmware). If you're worried about the security implications of leaving telnet running, you can shut it off until you need it.