We’ve all been there. You try to load a web page, or check your email, or download a file, and nothing happens. “The Internet’s down!” is the cry at my house when we lose connection. It’s also the #1 reason why people call their Internet service providers’ tech support numbers, which is undoubtedly why those companies’ automatic call answering and routing services universally suggest “power cycling” your modem and router first, which clears up the problem 9 times out of 10.

“Power cycling” a device simply means unplugging it, waiting a short period of time, and plugging it back in. In devices like modems and routers, the short wait period allows the volatile memory (referred to as VRAM) to fully clear before getting a fresh start upon re-connection. But if you really want to be an ubergeek, manually power cycling your equipment just won’t do. This is one possible approach to restore your geek cred.

First, you need a power strip that can be remotely managed. I use a BayTech RPC3-20, which I actually got for free a few years ago when a friend’s company was decommissioning a batch of them. I’ve seen used ones on eBay for under $100. It has eight power receptacles in the rear, an Ethernet port on the front, and a simple text-based embedded OS accessible via Telnet or SNMP that can provide feedback on the unit status (temperature, current, ON/OFF states) and allow control of the switched outlets. I plug my house’s main gigabit switch into Outlet 1, my cable modem into Outlet 2, and my router into Outlet 3. I then plug the RPC unit into one of my rack’s battery backup units so that the power to the outlets only gets disconnected when I want it to. 🙂

Next, you need a computer that’s running all the time. I use an old Dell PowerEdge 2450 that used to power one of my work projects. It runs CentOS 6 Linux, and I keep it around mostly for testing, but it’s also perfect for little tasks like this. The system has a cron job set to run a shell script every 10 minutes that checks to make sure it’s still connected to the Internet. If it determines it’s not, it triggers a second script that logs into the RPC unit and power cycles the two outlets that power the modem and the router.

The first shell script, called check_comcast.sh, looks like this:

Big thanks to my homeboy Steve Cook for authoring the initial version of that shell script.

You can modify the three remote servers to your liking. I simply chose Comcast, Yahoo, and Google because I figured they’d be reliable. The script pings up to three remote servers (you could add even more, if you like). If any of the remote servers replies to the ping, the script assumes you’re online and ends. But if all three fail, the script knows something’s wrong, sends me an email with the script output, and then feeds a separate PHP script to the local telnet client. The email line of this first script is configured for use with Comcast’s SMTP servers. The first version of this script used the local mail function on the server to send the message, like this:

date | mail -s 'Reboot Alert' [email protected]

but because the mail originated from a server on a residential IP address, the message usually got trapped by Spam filters, so I changed that line to authenticate on my ISP’s mail server instead. I recommend you do the same and edit that line for your situation. You may be wondering how an email can be delivered if the Internet connection is down. Thankfully, the command line SMTP client used in the script (smtp-cli) will retry a few times before giving up. If the power cycle is successful (and it usually is), the message gets delivered on the first retry.

The second script in this approach, which does the rebooting, is a PHP script that feeds commands to the local telnet client, like this:

It opens a connection to my RPC unit on local address 192.168.1.200, authenticates with a username and password, tells the RPC to reboot outlet 2 (the modem), tells the RPC to reboot outlet 3 (the router), then logs off.

After you’ve got the scripts working, the final step is to automate the scripts with a cron job. Mine runs every ten minutes:

0,10,20,30,40,50 * * * * /usr/local/bin/check_comcast.sh

Easy as that!

An added benefit to having an email record of how often (and approximately how long) your Internet was down is the ability to contact your Internet provider and request a service credit in the event of a prolonged outage. It’s hard for them to refuse if their records match yours concerning when things were offline. 🙂

I welcome your questions, comments, or suggestions for improvement below!