DynDNS using Crontab on Ubiquiti airMax/airOS

In latest version of their airOS firmware for airMax devices Ubiquiti networks dropped support for Dynamic DNS services. This left me out in the dark, unable to update the dynamic DNS corresponding to my devices. After a lot of crawling around the support forums I eventually came to a working solution based on crontab.

I use services from Hurricane Electric for my dynamic DNS needs. Updating boils down to fetching a special URL using either wget or curl. My idea was to do this every 30 minutes using cron jobs. This would have been done within a couple of minutes on a regular Linux system but turned out to be less straight forward on Ubiquiti device.

The airOS system ships with crond, however it is looking for its crontabs files in the inexistent /etc/crontabs folder and it is not started on boot. What we will do is create custom scripts to run crond on boot and use our own crontabs directory.

Prerequisites

  • An airMAX Ubiquiti device running a Custom Scripts capable firmware. Get it from here. I am using version 8.7.1 at the time of writing.
  • SSH access to the device
  • Know-how on editing files using vi editor (there are plenty of vi tutorials on the internet)
  • Familiar with cron jobs

Getting it done

Create or edit the poststart script using vi editor. This script will be run after the system has started.

vi /etc/persistent/rc.poststart

Below is the content of the rc.poststart script. It basically only starts crond telling it to look into our own (not yet created) crontabs directory.

#!/bin/sh
/bin/crond -b -c /etc/persistent/crontabs -L /dev/nullCode language: JavaScript (javascript)

Make the rc.poststart script executable and create the directory where our crontabs will be stored.

chmod +x /etc/persistent/rc.poststart
mkdir /etc/persistent/crontabs

Edit our cronjobs

crontab -e -c /etc/persistent/crontabs

This is how my cron job to update my dns looks like (it is anonymized here).

*/30 * * * * /bin/wget -O /tmp/updatednsresponse.txt http://myhost.mydomain.com:myPassWord@dyn.dns.he.net/nic/update?hostname=myhost.mydomain.com > /tmp/updatedns.log 2>&1Code language: JavaScript (javascript)

Save everything between reboots !

Once done and on every change, in order to apply your changes you need run the following commands. This will save the changes (actually all that is contained in /etc/persistent plus other config stuff) and reboot the system.

save
reboot

Sources

Here are the partial information (not exhaustive list) I collected to achieve this :

https://community.ui.com/questions/Do-you-use-custom-rc-X-scripts-on-airOS-devices/3042d465-a508-4bb0-9eb8-f7f2be109b8f#answer/b0f6ba92-7c39-4a9e-bde3-4abb15ee7e1c

https://community.ui.com/questions/Trouble-getting-rc-poststart-to-execute/e9166419-857f-4244-a257-b6d52e7f63e7

3 Comments

  1. Excellent and easy! Though, I dislike using the “Custom Scripts” firmware. I can think of a couple “creative” alternate mechanisms that would require a remote server to perform the DDNS updates on behalf of the remote AirOS devices:
    (1) Use the System Log service remote log feature. The receiving server would take note of IP address changes and update DDNS.
    (2) Use the Ping Watchdog service to regularly ping a server elsewhere. If the server sees a ping from an address it doesn’t recognize, it would attempt to identify the unknown sender. One possibility is a Telnet connection attempt on AirOS, which returns “[device-name] login:”.

    Kevin
    1. Hi Kevin,
      Thank you for your comment. I like your first option, the one with the ping seems to be prone to hijacking.
      Is there any particular reason why you do not like custom scripts firmware ?

      1. I think your method is probably best. Custom scripts is supported by Ubiquiti, but denoted as “slightly less secure”. And updates aren’t immediately available. Obviously, my ping method would require some defensive mechanisms. For starters, maybe set the ping interval to something odd and not respond until several pings occur at the right interval. I don’t like the idea of opening up Telnet, though. There are other ways to verify the ping sender. Your method is quick and makes good sense. I’m just thinking creatively. Thanks for posting this solution! Long-time HE customer here.

        Kevin

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.