Friday, September 4, 2015

dynamic DNS on DD-WRT won't update after power up / boot

my setup is a dsl modem with a DD-WRT based buffalo router, configured to use DDNS to connect to i've tried the modem in both bridge mode and router mode. after a cold start, ie after both the modem and router have been powered down and the phone line disconnected, the IP address doesn't always get updated and the "DDNS Status" log shows:
Thu Jan 1 00:00:50 1970: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
Thu Jan 1 00:00:50 1970: INADYN: IP read from cache file is ''. No update required. 

the problem appears to be a race condition between the new IP address being assigned and the DDNS check (the "thu jan 1" date suggesting the time of day hasn't updated either). a fix is suggested by:
Go to: Administation-> Management 
In Additional Cron Jobs write: 
*/10 * * * * root /usr/sbin/inadyn /tmp/ddns/inadyn.conf > /dev/null 2>&1 

which runs the inadyn command every 10 minutes using cron. i've just applied/saved this setting. the DDNS updated immediately after applying this. since the problem was intermittent, i can't know if it's solved. if the problem reoccurs, i'll update this post

edit 2018.01.24:

i ended up disabling the cron job years ago, i believe because i was worried about the logs filling up memory. or perhaps because it resulted in multiple inadyn processes running. at this point, i'm still not sure if it ever really (since the problem is so intermittent) worked

i just disabled the external ip check

but i understand the fundamental issue better now than i have. inadyn is running, but failing to recognize that the cached value differs from current value. there's a verbose option for the config file, but i don't currently have it enabled (the UI doesn't have an option for it). i believe that there's a way to use the nvram tool to manually fix it, ie without the UI, but i haven't delved into it yet

good description of how to force inadyn to restart shortly after booting (to allow it to pick up the correct ip address):

an unrelated issue is that the sshd running on the router only supports a no-longer-current encryption method and ssh by default refuses to connect, so need to use a workaround

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@

(i provided a public key, but it's likely that this would work for password-based login too)