Multiple DDNS Accounts

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search

Revision as of 19:12, 18 August 2006

DD-WRT v23 SP2 and later use inadyn as its embedded dyndns client solution.

Contents

Background

By default, the DDWrt GUI allows the specification of one DDNS provider e.g. dyndns. At router startup, DD-WRT launches inadyn in daemon mode, and from this point onwards, inadyn manages updates to the DDNS provider. inadyn retrieves the DDNS provider parameters (username, password, provider name etc.) from DD-WRT via a configuration file (/tmp/ddns/inadyn.conf), that DD-WRT creates from information entered by the user on the DDNS UI screen.

However, the base DDNS implementation in DD-WRT updates one DDNS provider only. Some users may have multiple DDNS providers, and associate multiple URLs with their IP address. This wiki shows how to maintain these multiple DDNS accounts by using the embedded inadyn in DD-WRT.

The new DD-WRT integratino of inadyn

inadyn is a non-persistent program i.e. it does not maintain any state or information from one session to another. This creates a problem for DD-WRT in that if inadyn is restarted for some reason (e.g. a router reboot), a couple of key pieces of information are lost:

  • The WAN IP address the last time inadyn was run.

inadyn decides whether to do an update by comparing the last WAN IP address it saw with the current router WAN IP address. Thus when it starts for the first time, if it has no memory of the last IP address, it will always issue an update. Without some provision of supplying inadyn with this last WAN IP information, inadyn will always issue an update on startup, which has the potential to cause problems with DDNS providers like dyndns, that suspend their DDNS service to users who do frequent IP updates.

  • The amount of time left before inadyn issues a compulsory update

iandyn can be configured to always update a DDNS provider at a fixed interval. By default, DD-WRT sets this to 28 days. If for some reason inadyn is restarted part way into this schedule, it needs to know when the next compulsory/forced update time is e.g. if it was killed on the 27th day, if it has no information on how far along it was before, it will start counting from 0, and not do an update for another 28 days, thereby incorrectly stretching the compulsory period from 28 days to 27+28=45 days.

The new inadyn integration with DD-WRT upgrades both DD-WRT and inadyn to maintain these two pieces of persistent information in nvram. On router startup, these nvram values are written into files in /tmp/ddns for inadyn to retrieve, and from then onwards are updated by inadyn as it performs its updates.

When we extend DD-WRT as outlined below, we must also provide some means by which inadyn can maintain these two pieces of information in a persistent fashion. For the purposes of this section, we will assume that this is JFFS2.

Requirements

V23SP2 or V24 build from 18 August 2006 or later Some JFFS2 space to hold 4 small text files (config file, log file, cached IP, cached forced-update time)


Step by step instructions to manually setup the management of a SECOND DDNS provider on JFFS2