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’.



I no longer have an IPv6 address.

This morning, the Teredo server I subscribed to, refused permission to my client, to obtain an IPv6 address via proxy, with no explanation given. Therefore, I have discontinued my use of IPv6 addresses.

It’s no big deal, because nobody was connecting to my server anyway, using IPv6.



My Site mainly Requires Web-Sockets.

The origins of HTTP were essentially ‘sessionless’. This meant that with a server always listening on Port 80, a client could request one URL at a time, in response to which the server would return the page in question directly to the client’s port number. This included the CGI-scripts’ FORM data. But as the early Internet evolved, Web-sites started to become ‘session-aware’. I explained this to my friends in the past as follows:

The client connects to the assigned port number 80 on the server, and requests a session, which causes the server to start listening on another port number, this forming a ‘session socket’. The one listening on port 80 was the ‘server socket’. The server’s session socket was dedicated to one client and to one session.

My friends did not acknowledge this description of how TCP works, I think mainly, because I did not use the right terminology. What I had referred to as a ‘session socket’, is officially termed a “Web-Socket” in the case of HTTP. It turns out that with an Apache server, many sub-processes can bear these Web-Sockets. They don’t exclusively exist in order to output Web-pages at a faster rate, in response to individual requests made by the clients, to the process still listening on port 80.

One fact to know about my site, is that for such purposes as viewing this blog, the use of Web-Sockets is required. In the case of certain other sections of my site, such as http://dirkmittler.homeip.net/GallIndex.htm, the use of Web-Sockets is not required, because those Web-pages exist mainly in a sessionless way – they can be fetched one at a time without error.

Certain proxy-servers will not allow a Web-Socket to get forwarded. These are logically also proxies which don’t allow SSL connections to be forwarded, because the encrypted SSL data is also sent via Web-Sockets or their equivalent. If you are connecting to the Internet via such a proxy, I’m afraid you won’t be able to navigate my blog correctly. I apologize for this, but there is little I can do about that. I think that you should still be able to fetch a single posting of mine, that comes up through a search engine.


(Edit: ) This may also apply if you’re trying to connect to my IPv6 address, because my IPv6 is being provided by a Teredo proxy, which might have just assigned reduced privileges to my client:

Previous Post