## DSL Modem Failure, Downtime

Atypically, I host this Web-site on my private server at home. When I got home today, I found that the DSL Modem / Router, which I rent from my ISP, had gone into a partially failed state, in which WAN access was still ‘normal’, but where attempts to obtain new IP addresses were not succeeding – i.e. My smart-phone could not connect to my WiFi when I got home. Also, maintenance access, which has only been enabled from within my LAN, did not succeed to check the router status.

The only solution I could think of, was to unplug the modem, wait for 60 seconds, and then plug it in again. This seemed to work, and my maintenance password to the Modem / Router has not been changed. I.e., I was not hacked. I was able to log into the Router again.

But power-cycling a router like that causes the network (LAN and WAN) to be unstable for several minutes. As a consequence, my site, and this blog, were not visible to the Internet from about 13h05 until 13h20.

I apologize for any inconvenience.

Dirk

P.S. Also, I now have a new, dynamically-assigned IP address. But this could be routine, as my domain-name should resolve to the new address anyway.

(Edit 09/11/2016 : ) I gave the command at 13h16 the same day, to propagate my new IP address, and my own router, acting as my DNS server, reflected the new IP address, still within 13h16. It should not really have taken most readers until 13h20, before their browsers would have been able to fetch my URLs again.

## RTL8723BE WiFi Stable Under Linux

On the laptop I name ‘Klystron’, I have kernel version ‘‘, and the misfortune of a WiFi chip-set that uses the kernel module ‘‘ with its companion kernel modules. Fortunately, I believe that it finally, fully stable!

I think that the most important detail on my part to getting this kernel module stable, was to add the file ‘‘ to contain the following code:


options rtl8723be fwlps=0
options rtl8723be swlps=0




Yet, as a series of blog postings already shows, it was not so quick and easy to obtain stability. One reason I think that my WiFi was failing on me recently, was my persistence in trying to put the laptop to Sleep, aka “Suspend To RAM”. This was never fully supported, and after Resuming from this sort of suspend mode, the WiFi would always be unstable. The only way I had to remedy this, was to change my user-level configuration, never to put the laptop to Sleep again.

Even with the WiFi supposedly stable in this way, the malfunction remains, that for any duration of time I close the laptop lid, the WiFi temporarily cuts off, which I think is a problem with the antenna. My solution: Leave the laptop idling, with its lid open. The result: Days and days of steady connection. Some small amount of dust on the laptop keyboard.

But there seemed to have been another problem with my WiFi specifically. The modem-router which I rent from Bell seems to have a specific policy. It sets itself to be the DNS server for my LAN, which downloads the IP addresses from its DNS parent. The WiFi router seems to have a zero-tolerance policy, if any computers try to bypass it as my DNS server. And this problem can be so strict, that even to have my LAN machines act as server, will cause problems and stability issues, which mimic hardware WiFi disconnection issues.

In my ‘‘, I needed to set


wins support = no

dns proxy = yes




Otherwise, the member servers would fail to see each other as Samba-connected, and finally lose their connection altogether.

Further, I had scripted the idea into my configuration files, to prepend IP address 8.8.8.8 as an additional DNS server into ‘‘ on boot-up, just hoping to obtain wider connectivity. But then one additional problem with that was, that this public DNS server would suggest IPv6 addresses in addition to IPv4, and that even though my user-level settings for the network said to ignore IPv6 addresses, a malfunction in the kernel – which has not bee remedied – would cause the WiFi client to try to request the IPv6 addresses anyway. My user-level settings were being ignored.

Thus, I think that getting rid of the 8.8.8.8 was instrumental in achieving stability.  Since this router does not tolerate IPv6, and since it is now my only DNS server, there is no risk of IPv6 addresses ever getting mentioned on my LAN.

On that note: It is normal on a dual-stack machine, for each NIC to have an IPv4 as well as a local, “Link” IPv6 address. But I think that one aspect in which the behavior of Ethernet cards is different from WiFi, is that the Ethernet card will not try to use its IPv6 address, because that will recognize this is not a global address, which would need to be assigned by the router. It would only try to use its “link” IPv6, if it was to try to connect directly to another machine on my LAN. OTOH, It would seem that a WiFi chip-set will not recognize that its IPv6 is invalid, and will ask for “Global” IPv6 addresses.

This can be an embarrassment, if the router did not specify any, and if the router assumes that it is the only DNS server.

Dirk

## Monthly Log Rotation Disrupted my IPv6 Today.

One of the tasks which a Debian / Linux system does, is log-rotations at regular intervals. Some log-rotations take place daily, others weekly, and others monthly.

When log files are rotated, the services that generate them must usually be restarted, although there are a very few daemons which can simply be commanded to reopen their log file. This needs to be done, because even when the name of the log file has been changed (by the log-rotation), the file handle which its process has, still points to the same file. So most generally, the service is also restarted, so that it can open a new log-file, with the name of the old log-file, which was rotated to having a new file-name.

I have two services installed, to which this is relevant today. One of them is my “OpenVPN Server”, and the other is my “Teredo Client”. The Teredo Client was already configured by package maintainers, not to do any log-rotations. But my OpenVPN Server does a log-rotation on a monthly basis.

One of the facts about how my system reacts is in practice, that when my OpenVPN Server does a restart, it also incapacitates my Teredo Client. I am not sure why this happens, but it is completely consistent behavior. It has something to do with how my dual-stack kernel manages its IPv6 addresses.

So today, being July 1, saw a log-rotation to my OpenVPN Server, which also took out my Teredo Client, at the time the monthly log-rotations are supposed to take place, in a 100% predictable manner. I needed to restart the Teredo Client, in order to get my IPv6 address back, by about 14h15 this afternoon. From about 6h00 until 14h15 today, this site had no working IPv6 address.

I apologize for any inconvenience.

Dirk

## This Time, a Routine IP Address Switch

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.

Dirk