Ddns.nu remote update client
ddns3 --user user --pass password [ options ] command ...
ddns3 updates IP-Handles on the ddns.nu remote update server. This allows remote automated updates rather than using the website via a browser.
Specifies the username to authenticate with.
Specifies the password to authenticate with.
Override the default server hostname to connect to. The default server hostname is ns.ddns.nu.
Override the default TCP port to connect to. The default TCP port for the ddns3 protocol is 2164
Specify what type of authentication protocol to use. The available types are: plaintext, crypt, md5, ddns, and strong. The default type is ddns which is secure in the sense that the username is sent in cleartext, but the password is sent hashed in such a manner as to defeat replay attacks by utilising a salt sent from the server.
List all IP-Handles and their current values for the account. You may do this multiple times, for example it is perfectly legal (and perhaps even useful) to do a list, followed by a set, and then another list to observe the change.
Set an IP-Handle named handle-name to the IP value ip-value. Similar to list you can specify as many such operations on the command line as you wish and they will be executed in the order specified.
Set the IP-Handle named handle-name to the IP value derived from IP seen by the ip-source end of the update connection. The ip-source is specified as either remote or local. Again you may specify multiple guess commands on the command line and they will be executed in order.
Using the local option saves you from having to specify the IP on the command line. Local guessing usually gets the IP correct as it takes the local address of the socket making the update connection. With conventional routing arrangements this is likely to be the IP you want.
However the remote option sets the IP-Handle to the IP that the server sees the connection as originating from. This is most useful if you are running the client from behind a NAT gateway which itself is incapable of running the client. In this case the IP of the NAT gateway is used, rather than the probably martian IP of the host the client is actually executing on.
Useful error messages are produced on stderr, all other runtime output goes to stdout.
On runtime exception the return value of the process may be useful in scripting:
-1
The usage message was generated by running the command with no arguments.
-2
The argument parser didn't like the command line.
-3
A connection could not be established with the update server.
-4
Authentication failed.
-5
Network errors closing the connection (these can often be ignored).
-6
Some kind of internal logic error in the process, like a malloc/free failure.
The process returns a positive count of the number of commands executed on the server that generated an error, or zero on error free completion of all commands.
The authentication details should be read from a file to avoid their visibility in the process list. There should be support for other ddns3 protocol primitives like MOTD and HELP for completeness. The java implementation jddns3 does this, and is largely command line equivalent. Short network writes are unchecked in at least one place.
Alan Yates <[email protected]>
$Id: ddns3.1,v 1.2 2003/03/20 05:21:59 alany Exp $
http://www.ddns.nu/
http://www.ddns.nu/files/ddns-v3.txt