A Potential Solution to DynDNS Update Client

This posting is about the error messages which many users of “DynDNS” Automatic Update Client have reported, and which were also preventing my own update client from doing its job. The error messages were of the form:

API Request Failed. Status 500 Method ipaddress.get

Some sources on the Web suggested this had to do with their user-names and passwords on the DynDNS server being corrupted, and performed a reset of those. Other sources reported, that if they switched the configuration of their IPv4 and IPv6 fields to ‘Static’, and then back to ‘Automatic’, they could get the updates to resume.

Unfortunately, neither of those solutions worked for me. And in order to illustrate why, and what can go wrong, I must first explain my configuration in greater detail.

I have the internal loopback interface named ‘lo’, the real interface named ‘eth0′ (which only has an invalid, LAN IPv4 address), and the virtual interface named ‘teredo’ (which offers a tunneled IPv6 address). In the configuration of my DynDNS host, on the client program version 5.2.0-2, the choices for both IPv4 and IPv6 are ‘Disable’, ‘Automatic’, ‘Local Interface’, and ‘Static’. They key to understanding the problem in my case only became obvious, when I tried to configure ‘Local Interface’. The drop-down menu only offered me the choice between interfaces ‘lo’ and ‘eth0′, with ‘lo’ being the default.

Hence, the Python script was written to disregard the virtual interfaces on my host, including the interface ‘teredo’, which is providing IPv6. And additionally, with both IP versions set to ‘Automatic’, it did not recognize which of my interfaces to use for IPv4.

The solution for me was, to set the IPv4 resolution to ‘Automatic’. Next, the only way for me to set my IPv6, is manually through ‘Static’, which I can read from the root command

ifconfig -a

Granted, to have to set my IPv6 address manually is not ideal. But what was worse, was the fact that my IPv4 was not being updated automatically, which it now knows how to do.

I hope this insight helps some other users, who may have run into this ubiquitous error message for different reasons. I don’t really see, why we wouldn’t at least want to set the ‘Interface’ manually – except for cases where that has been NATted – and I guess IPv6 resolution is meant for users, who have a ‘Native IPv6′ and not a ‘Teredo Tunnel’.