Routine Log Rotation Suspended my IPv6 Today.

Today is May 1.

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.

So as I am writing this, I have an IPv6 address again.

Dirk

 

I do not own my own router.

One thing which exists in a big way in Canada, is that ISP subscribers own their own router. But as it happens, my router is owned by Bell and rented to me. The official reason for this, is the fact that my router also provides me with Bell Fibe TV, which contrarily to the naming, is in fact provided over IP via DSL twisted-pair wires.

This paid-for TV content is DRM, so that it is hard to imagine that any other computer enthusiasts have managed to set up their own router, and to receive Fibe TV anyway.

But this also means that I do not have the access to flash my own router. Bell can flash the router when they see a need, but I cannot. And this also means that I cannot obtain full control over this router.

Readers might think that this is an odd situation, for a person who sets up a Web-server, and an OpenVPN-server, at his home IP address. But by using IP-tables in my Linux configuration, I have been able to do precisely that. In particular, the OpenVPN-server requires an ‘IP Masquerade’ to work. But as of my last test, it does work.

But because I am a person who ‘sometimes thinks suspiciously’, I have also had ideas, about what other consequences might arise, from the router being under the control of somebody else. One thing which may happen, is that this router, which displays no options or information regarding IPv6, may get confused and start dropping clients, over repeated requests for IPv6 addresses.

The Web-interface of this router is a dumbed-down interface, which I can access, but which for my benefit, does not give me deep control over the settings. One thing which remains true however, is that in Canada, there is next to no real use of IPv6 from the side of ISPs.

Now, I have set up an IPv6 gateway, which allows my site to be fetched by way of IPv6 if this is desired. But I have also set up my ‘ip6tables‘ in such a way that any request my Server makes for an IPv6 address, gets routed to this gateway, and not to my physical Ethernet connection. It is only logical. So ‘ping6‘ works gloriously on the Server, but not on my laptop. When I do a ‘ping6‘ on my server-box, I also get to see a graphical display in my ‘gkrellm‘ monitor widget, of activity going out over my ‘teredo‘ virtual NIC, not over my real NIC.

And so I have a somewhat lopsided configuration at home, but one which does what I want it to do.

Dirk

 

Stabilizing my Realtek rtl8723be WiFi card under Linux.

The laptop of mine onto which I newly installed Kanotix / Spitfire, and that is named ‘Klystron’, happens to have a Realtek rtl8723be WiFi chip-set, which is known to have stability issues under Linux. I found that recently my own experience also ran into these issues.

If you feel that you are also having these issues, it is important that you first check, whether in fact you have the WiFi card in question. This can be done via an ‘lspci‘ command, or with


lsmod | grep rtl8723

I felt that I needed to apply a two-prong solution to my own problem.

The first thing which I did, was to create a file named


/etc/modprobe.d/rtl8723be.conf

The only content of which was the line


options rtl8723be fwlps=0 swlps=0

This solution may solve the problem, of the WiFi dropping the connection, after periods of idle time.

There is something to watch out for. There are some sources on the Web, which state that we should try  the configuration line


options rtl8723be fwlps=N swlps=N

The problem with this method is, that for certain uses in programming, in particular in the language C, which is used for kernel modules, a numeric value may be expected in place of a Boolean value, and if in this case the module sees an ‘N’, this value will not be equal to zero, because the ASCII code for ‘N’ is not zero, and any other value than zero is taken to be True! So to make sure that the kernel module registers False, we need to put a ‘0’.

But I found that a second issue was affecting me, which was the fact that this WiFi setup has IPv6 enabled, but that my router does not tolerate IPv6. This may have been causing my laptop to get dropped from the WiFi, even as I was downloading software. In my dhcp configuration, I have added the DNS Server 8.8.8.8, which is the free Google DNS server, in addition to the auto-detected server. But 8.8.8.8 will offer the system an IPv6 resolution of a domain name along with an IPv4 resolution, and in the case of WiFi, apparently Linux will use the IPv6, without detecting that this ability was not assigned by the Access Point.

And so I felt that I also needed to disable IPv6 system-wide on this laptop. The way to do that was to add the following lines to the file ‘/etc/sysctl.conf‘:


net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

And then ‘sysctl -p‘. After that, I also did


update-initramfs -u

This is a very sticky issue, in which different users have reported, that some of these solutions either do or do not work for them. One reason may be, that users are in fact reporting different issues without knowing it. I cannot be sure that this solution will remain 100% effective for myself, let alone for the reader. I just wanted to share my own experience with this. So far, my WiFi chipset is stable again.

(Edit 04/12/2016 : ) Just to prove to you, how uncertain the state of that WiFi chip-set is, even though I did change the parameters fed into this kernel module, it still happens that when I leave that laptop idling overnight, its WiFi goes into suspend mode. This happens in a way which the applications usually do not see, so that those applications still think they’re connected. However, my ‘Pidgin’ IRC Client gets disconnected.

And then, when I resume my session, ‘Pidgin’, which uses a ping timeout, did realize it was disconnected, and just reconnects seamlessly. And this latter part seems to happen, directly after I unlock my screen-saver, which seems to suggest that this is not being introduced by the Kernel Module, but rather by KDE, etc. I suppose it might introduce some level of confusion into the software, if the Kernel Module was to provide the same function again.

So who knows, which of my problems – if any – I may really have fixed?

Just checking my package manager, I see that ‘Pidgin’ has an available ‘Away-On-Lock’ plugin, which was not installed. Just this evening I installed and activated that, just to see whether I can override a behavior, which might have been set erroneously to ‘Offline-On-Lock’, while the plugin was not installed… By tomorrow, I should know.

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