Meta

Tag: Teredo

This little project kept me up late last night, and also accounted for a brief interruption in my server availability between 21h00 and 22h00.

I have set up a Teredo gateway, which gives limited IPv6 availability by way of an IPv4 tunnel, and which presents the local computer with a virtual IPv6 NIC. The ultimate goal of this exercise was, that people in the WWW who have native IPv6 access, should be able to access my site using this IPv6 address.

Right now the global address in question is ‘2001:0:53aa:64c:302a:2849:b9e5:30c7′, but it may change at any time.

While it seems superficially that I may have succeeded at achieving this goal, I am unable to give it a thorough test, because the Teredo gateway also does not allow loop-back access. For me to try loop-back access, I need to use the IPv6 address of the loop-back interface provided by my kernel, which is ‘::1′. The problem with this is, that it does not provide a thorough test, or even an adequate test. Certain single Web-pages display fine.

But in order for my blog, for example, to display correctly, it is not only the main, home page of the blog which must get served up, but also the many individual URLs embedded within that main page-view. And then what seems to happen with my own PC, is that even if I specified the IPv6 address literally as a URL to fetch (which requires embedding it in square brackets), all the embedded URLs are still resolved to the IPv4 DNS addresses by my browser, resulting in an inconsistency, which I believe will prevent any complex page from displaying.

The only way this blog will display correctly using its IPv6 address, is from a client, on which every reference to my host URL has an IPv6 resolution.

I have paid closer attention, to the ‘Internet Connection Failure’, which I just posted about Here. Even though the public cannot read my blog right now, the way I am set up, still allows me to write entries.

When I checked my DSL more carefully, I noticed that I do not have a dial-tone. And, every half hour, to every two hours apart, the DSL connection is dropping out on me. This does not seem to have been a problem with the router per se.

For the past few days, Montreal has been experiencing continuous, heavy rainfall, starting on ?Tuesday? The weather is going to stay this wet, until tomorrow (Sunday). I suppose that what can happen, is that excess water can seep into the cables, and can cause those DSL wires with the weakest insulation to fail. I hear crackling noises when I listen on my phone, for an expected dial-tone.

Certain services are more sensitive than others, to errors in the transmission of packets. It would seem that the Teredo gateway has no tolerance for those at all, for which reason it was dropping my client connection frequently.

And, had I left things as they were, the ‘DynDNS’ service would have attempted inexhaustibly, to keep associating new IPv4 addresses with my URL, even as the modem was dropping the connections, and establishing new ones.

The only responsible thing I was able to do in response, was to shut down my DynDNS service for now, to avoid future, excessive update-requests, which also means that the public cannot be reading this as I am writing it.

The technician from my ISP is scheduled to come by on Tuesday, to see what can be done to remedy this problem. And my blog and site will have to remain offline until then.

This time around, my ISP made a routine switch in my home IPv4 address, which my DynDNS software was able to follow, without any intervention on my part. This Earlier Posting explained, that a switch can also take place, which the software fails to follow automatically.

And this time, I did need to update my IPv6 (Teredo) address manually. It is to be assumed that IPv6 address changes of my server need to be updated manually, as explained in This Earlier Posting.

Hence, since last night, my IPv6 was unavailable until 13h15 this afternoon.

On most Linux systems, there are “log rotations” which can take place daily, weekly, or monthly. Log rotations frequently but not always require that a service be restarted. This is because while log files have been renamed, the service which is writing log data to them, retains a handle to the same file as before, unless that service is restarted. Once the service is restarted, it obtains a new handle from the O/S, for a fresh log file.

Most of my log rotations have no side-effects. But when I set up my ‘OpenVPN’ -protocol VPN server, I decided to set up a monthly log rotation associated with it, which also has as post-log-rotate job, to restart this VPN.

Oddly enough, this does not impede the VPN service from restarting. But as a side-effect, this knocks my (Debian) ‘Miredo’ client off-line every time, which gives me IPv6 connectivity when it is running, by way of a Teredo server.

It seems that the authors of ‘Miredo’ have already observed, that restarting something that upsets the IP stack in this way, can knock their client off-line, and so the makers of this package omitted any logging, or log rotation, for ‘Miredo’. But whenever by VPN server is restarted, this affects the Teredo client I just named.

Today is May 1. So therefore in a routine way, my IPv6 address was knocked off-line by the monthly log rotation this morning. And this effect lasted, until I manually restarted the Teredo client in question.