Scheduling Reboot of Motorola Cable Modem

UPDATE: This no longer works for me because a recent firmware update removed the Restart command from the web interface.

Periodically my Motorola SURFboard SB6141 cable modem stops talking to the outside world. I don’t know why, but restarting the modem fixes it every time. Rather than having to regularly power-cycle it by hand – or, heaven forbid, buy new hardware – I decided to schedule an automatic reboot.

The modem itself doesn’t have a facility for automatic reboots, but it has a web page with a button to restart it! <> So all we have to do is automate the clicking of that button.

If you have this model, or a similar one, this command should work. Just paste it into your terminal/console program and hit Enter, and see if you temporarily lose connectivity to the Internet. If you do, then it worked:

/usr/bin/curl -G -d reset_modem=Restart%20Cable%20Modem > /dev/null

Once you verify it works for your modem, add it as a cron job. Mine looks like this, running daily at 4:30am:

30 4 * * * /usr/bin/curl -G -d reset_modem=Restart%20Cable%20Modem > /dev/null


  • The only real dependency is that you have curl installed. On Mac OS X, CentOS, and Debian it lives at /usr/bin/curl but if you’re using a different distro/OS you’ll want to make sure the path is correct.
  • Verify the IP of your cable modem is correct. For most/all Motorola models it’s but try Googling yours if that doesn’t bring up a status page in a browser.
  • If the IP is correct, make sure the values passed by the restart button are the same as my example. (Go to the page that has the button, make sure that URL matches my example, then view source to make sure the name and value of the button match.)

Yosemite Captive Portal Fix

A number of Yosemite Macs are having problems with our organization’s Wi-Fi captive portal.

If you don’t first sign in via the window presented by Captive Network Assistant, the system appears to have zero network connectivity. You can’t ping anything, you can’t perform DNS lookups, etc. It’s as if the OS is actively blocking all attempted connectivity until it knows you have succeeded in authenticating.

Consequently, Browsers throw errors instead of presenting our captive portal page. This is a big problem, since in many cases the Captive Network Assistant app was previously disabled or deleted!

I found I could whitelist our network so that it lets applications try connecting even if the Captive Network Assistant has not yet been placated.

Just copy the command below, replacing NAMEOFNETWORK with the SSID of your captive portal network. A reboot may be necessary, but it may also be enough to simply switch Wi-Fi off and on again.

sudo /usr/libexec/PlistBuddy -c "Add ScrapingParameters:DisabledRealms:0 string @NAMEOFNETWORK" /Library/Preferences/SystemConfiguration/CaptiveNetworkSupport/Settings.plist