Some Strange Malfunction on the part of My ISP

I do not own my own IP address. And this blog is not being hosted from an IP address I own, but rather from a personal IPv4 address owned by my ISP, which they allot me via standard DHCP protocol. Hence, my ISP is free to change my IP address, and to assign me a new one at any time, on the assumption that I only have an account for personal use.

When the ISP does this, I have software in place, that makes sure my domain names still resolve to the new IPv4 address, i.e. software which updates the DNS servers with my new address. I am a client of DynDNS.

But since last evening, there has been some unusual activity in this regard, in that my ISP did not only assign me a new IPv4 address, but did so roughly once per hour, until today.

While doing so only disrupted IPv4 access to my blog minimally, it did in fact disrupt IPv6 access to my blog. Right now I have updated my IPv6 address again manually, so that IPv6 access should be possible again.

But I do hope that this malfunction has now passed.

Dirk

 

My IP address was reassigned last evening.

I am hosting this blog on a personal Web-server, which connects to the Internet via a personal DSL. This may also be why downloading some of my content could have been slow for the readers.

I don’t own my IP-address. So my ISP can just cut that off, and reassign me a new one whenever they feel like it. When they do this, my LAN is still up – thankfully – but my link to the WAN – the Extranet – is gone for a  few minutes.

I have software which updates my IPv4 address automatically in this situation, so that this URL finds me again afterward. And I need to update my IPv6 address manually. But with any luck, these things can even take place without my being present, and most of my software just reconnects as it should.

And yet for the 5 minutes this can take, the readers might not have been able to retrieve my blog last night.

Dirk

 

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

Dirk