Say Hello to Failsafe

Life can be very exciting on the bleeding edge, but as I read the other day in a forum post, sometimes it means that you get cut. Figuratively speaking, I got "cut" the other morning as I attempted to switch my main router over to the glorious wrt54gl using my hand-tuned openWRT install. This did not go as planned.

I had spent the last week or so tuning the openWRT installation to do exactly what I wanted. I used one of my servers second NIC to simulate a connection to the internet. Something like this:


Such a setup allowed client1 to connect to the internet just like Server could. In my previous post I also spent time splitting up the WIFI and LAN networks to keep them independent of each other. Now, what I didn't do was to test the settings across a reboot of the device. Having not done this crucial step, I went ahead and swapped out my dlink for the wrt54gl. At first, things went well. My WIFI connection to the wrt54gl worked just fine and I could connect to the internet. However, nothing on the LAN was getting a connection to the wrt54gl. I logged onto the wrt54gl (via WIFI link) and looked at the config. After examining the routing table (rount -n), I noticed that the LAN network wasn't listed. I had configured WIFI to use 10.23.24.X and LAN to use 10.23.23.X. At first, I figured this was just a hiccup and attempted to bring the LAN interface up (ifup eth0.0). No such device. Huh. ifup et0. No such device. Booo. After about 10 minutes of nothing working, I figured I would revert the separation configuration and bridge the WIFI and LAN together. This was simple, just add the bridge option back to the config (/etc/config/network). Reboot.

At this point the bleeding had started. The WIFI associated with the wrt54gl, but I couldn't get an IP. I couldn't get an IP via the LAN either. I manually configured both WIFI and LAN and neither could connect to the wrt. Thinking for a but I suddenly realized my mistake. In the previous post, I mentioned some firewall rules. Specifically, I had entries to prevent the WIFI and LAN from passing traffic to each other. And now they were part of the same bridge. This meant that no traffic from either LAN or WIFI was getting into the device. The wrt54gl was bricked and I needed a tourniquet.

As hopeless it seemed, I had to assume I wasn't the first guy to hose up a firewall configuration on the wrt , locking one out of the device. And I was right. The smart folks at openWRT built in a failsafe mode.

I had already attempted to use the reset button on my wrt54gl, hoping that holding that during boot up might reset to defaults. This is true, but as the link described, it has to be done after the DMZ light turns on. Thankfully on my model, holding down before the light came one didn't trash the device. On the second try, I got it to enter Failsafe mode; DMZ light flashing three times a second. A quick reconfiguring of my ethernet interface and I was telnetting to 192.168.1.1 and greeted with the openWRT logo and a shell.

I chose to use the firstboot and sync method and before rebooting, I ran 'passwd' to switch over to ssh. I then rebooted the device and it came up with all of the defaults again. Whew! It was also good to know that even if the Failsafe method hadn't worked for me, there were still several other options: UDP broadcast message and TFTP booting. Great Job openWRT!