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.



Print Friendly, PDF & Email

Possible Mode Of Failure, of a Neato XV

I own a “Neato XV Signature” Vacuuming Robot.

Neato XV _1

This little thing has been vacuuming my floor 3 times per week. But this does not mean, that it never has any problems or malfunctions. I just discovered a possible malfunction, which caused it to stay stranded in my living room, close to the end of its assigned chore, but waiting for my intervention, before it would have been able to continue. And because I needed to focus and take my time to figure out what went wrong with it this Friday, my response was also to tell it, that its job was done for now, not to continue for one day.

This little machine frequently rides at relatively brazen speeds, over bumps in my floor, caused by such things as wooden strips in my floor, that separate regions of differing floor-type. So the little bot is wearing itself out as it is doing its job, and may not be with us forever, just for that reason. And yet, there is something more specific which can go wrong.

This vacuuming robot has a dust container made of plastic, which is transparent in some places, and which needs to be lifted out of its cavity in the robot, in order to be emptied, preferably after every use. The robot has a small mechanical switch inside this cavity, in order to detect, whether the dust container is fully inserted or not, and if the dust container is not fully inserted, will stop working and ask the user to remedy the specific problem.

The problem is the fact that there is no gap – no tolerance – between the outside surface which the dust container has, and the inside surface of this cavity within the robot, into which the dust container expects to be inserted flush. There is some mechanical action of the plastic, that causes the container to snap into place, so that the user can recognize he has done so.

After numerous months of repeated use, it commonly happens that dust – or even larger debris – can fall into the cavity, but land outside the container, so that effectively, particles and pebbles can get wedged between the dust container and the space inside the robot, where this is to be inserted.

The result of this is, that the user needs to push down a bit harder on the container, before he gets the tactile feedback, which usually lets him know that the container is fully seated. But in reality, the plastic of this device is arched, with some elastic force against remaining inserted – internal force trapped in the elasticity of the plastic.

Hence this past Friday, the robot passed over several bumps in its terrain uneventfully. But then, when it just passed over another bump, this internal force, together with the elasticity of the plastic, actually caused the dust container to pop out slightly, and for the internal switch to report to the computer of the machine, that the container was no longer inserted properly. This was also good, because as soon as the dust container does not form a proper seal inside the robot, the fan or turbine of the robot is also inhaling debris.

And so this little robot waited and waited for me to come home, and to rescue it from this dilemma. By then its battery charge level had also decreased considerably.

The only way to solve this problem, is once in a while, to take out the dust container, and then with it removed, to wipe and clean the inside surfaces of this cavity – where I found lots of dust and pebbles – to wipe and clean the entire outside surface of the dust container, and then to reinsert it.

I guess that the little machine might be good to go a few more times from now on, until it waits to be rescued from some other problem, that its robotic mind cannot solve.



Print Friendly, PDF & Email

Testing 802.11n

I have done some reading, into the subject of 802.11n speeds, over the WiFi chipset of my laptop, which its Realtek driver, supposedly supports.

The main fundamental fact to know about this, is that whether 802.11n speeds are in fact enabled, is determined from the router, and not as much from the local driver, where for all I know, the support could be without error.

This feature requires, that all the access to the router is set for 802.11n enabled, including in my case, the Guest Network, which was not so previously. More specifically, the form of security must be WPA2, not WPA1 or WEP, even for any Guest Network.

Where previously my client was set to using Channel 11, it now registers as using Channel 1, which means that although the used frequencies are in the same band as before, they can now span a larger part of this band, to support a single download or upload.

Further, in this mode, the slowest device on the LAN, also determines the fastest speed at which 802.11n will work, even when active. Hence, if I had an older smartphone and a tablet with poor or no 802.11n support, too bad, that tablet would set the limit, on how fast my WiFi speeds are going to be. In fact, both my phone and tablet are relatively recent, and have not interfered much in this trial.

When I run the ‘iwconfig‘ command on the laptop ‘Klystron’ as root, it tells me that “802.11bgn” is enabled, but that the maximum speed available will be ~72mbps. What this states, is the hardware limit of my WiFi chipset. This number already falls short of what 802.11n should allow, but is nevertheless the limit of my chipset.

Because of the DSL package I subscribe to, downloads to my LAN from the internet are limited to a much slower speed. Thus, I cannot use the Internet to test this. But I can use transfers from one computer on my LAN to the other, to test what my WiFi speed has become.

It used to be, that if I synced files between ‘Phoenix’ and ‘Klystron’, this local transfer was limited to about 1.5 Megabytes per second, while now that I have changed my configuration as described, I can get this transfer to take place at 3-4 Megabytes per second.

This low bitrate should not be alarming, because it is partially determined by how fast ‘Phoenix’, the older of the two machines, can encrypt the data, and the decryption of the data at that rate already consumes about 25% of the CPU time, on all 4 cores, belonging to the faster computer ‘Klystron’. This is not a speed test.

I have been wondering, whether I could have been suffering from an additional problem on ‘Klystron’, to whatever its behavior was when I simply closed the lid. And 2 additional things which may have been going wrong, could have been repeated requests from ‘Klystron’, to my router, of IPv6 addresses, while another could have been some half-formed use of 802.11n.

The way I now have it, any use of global IPv6 addresses from my laptop have been disabled, in ways that are safer for the configuration than what I had before. And support for 802.11n is currently enabled. If there is going to be some sort of malfunction, associated with this latter, enabled feature, I would like it to happen now, so that I can determine with some certainty, that there was ever an 802.11n problem with this chipset and driver. Personally, I am skeptical.



Print Friendly, PDF & Email

Some Thoughts about Laptop WiFi Antennae

One fact which I had observed for some time, is that even many laptops today which have an LCD display, still use an Electroluminescent back-light, the latter of which needs to be activated with a kilovolt voltage, but the first of which only receives signals from the motherboard, that are too weak actually to emit a lot of light. And so, the circuitry has existed for some time, to take battery-level voltages, and to boost those into the kilovolt range, resulting in a very small number of microamperes of current. This is done with transistors, and with a special coil – which is also called “an inductive component”.

What the designers of laptops with EL backlights tend to do, is to feed the thin leads which carry this high voltage, through one of the hinges of the display / lid, in such a way that the leads make a gentle 90 degree bend on the side of the MB, and make a gentle 90 degree bend again on the side of the lid, while inside the hinge that connects the lid to the main body of the laptop, this set of leads only makes a 90 degree twist, or untwists, as the laptop lid is opened and closed. It is felt that this solution minimizes any wear and tear to the high voltage EL power leads, the insulation of which may be thin, even though that modern insulation effectively stops 1-2 kV.


But there is a report about those leads which some readers may already have encountered, according to which those form the WiFi antenna of the laptop. Well according to what I seem to have observed myself, Those leads fulfill both functions.

Because the low-current circuitry which puts the high voltage onto those leads feeds them through an inductor, a radio-frequency signal can also be fed onto the leads without interference from the LF high voltage, simply by looping them through another device, in series with the high voltage source. Even the fact that they have ‘a bit more insulation than an RF antenna should need’, will not interfere with their working as a WiFi antenna.

And I suppose that a question which users might ask could be, ‘Why would the Engineers go through the extra trouble, to allow the EL supply leads to double as the WiFi antenna, when low-voltage loops on the MB itself should also work?’

And as nearly as I can make out, the answer seems to be, that on most laptop designs, the display / lid is the only larger component, which goes from facing horizontally, to facing vertically, during normal use.


So, depending on what sort of troubleshooting one is doing, one might worry, that the same leads which feed the backlight, might also be starting to fail, in their function as the WiFi antenna. There is just one observation which needs to be added, to this statement of a hypothetical fear.

If those leads did become so frayed, that they no longer work as an RF antenna, then the user should also see some sort of negative effect, on how well the backlight maintains constant brightness. In fact, very shortly after the onset of trouble, the backlight should also fail completely.

This is not impossible. I have had separate monitors fail, due to the supply to the EL backlight failing. That monitor simply went blank, within a second of my powering it up eventually.

But there is something else which can resemble this situation, which is not as negative a prognosis for a laptop. After all, if those leads needed to be replaced, doing so would effectively amount to a mess.

In the modern world of Quantum Mechanics, we might not like to be reminded of this, but practical antenna geometry is still defined by waves and nodal lines. The advantages of having put an antenna into a laptop lid can disappear completely, when we just close the lid and have the laptop idling in standby.

The geometry with which such an antenna sends and receives radio waves, can effectively collapse, just as a function of the lid being made horizontal again, flush with the motherboard.


So there could be a number of reasons for which a WiFi connection can fail, and I have just searched for a software problem, in ways that seemed to take me four ways to hell and back, when in my case, simply moving the laptop to the other end of the table it rests on, facing in an opposite direction, may have solved the problem for me.

I know that as long as the WiFi works 90%, and as long as my display works 100%, I will not need to dig any deeper into the inner workings of this laptop for now.


(Edit 04/30/2016 : ) One result which does not occur easily in Electronics, is the perfect separation of signals. Thus, closing the laptop lid will not reduce the amplitude of the received WiFi-signal to zero, but will only attenuate it. Likewise, if the same wire is being used as WiFi-antenna as is being used as EL power supply, using it for the latter, also injects background noise into the weak WiFi signal received as the former.

I now suspect, that whenever a Windows laptop lid is closed, Windows settings make extra sure, to turn off the display as well, so that this issue is less of  a real problem.

Further, one of the many, many KDE power saving settings we can decide, is that Laptop Lid Closing Action is Turn the Screen Off.

But beyond that, KDE has more settings. Typically, I will tell my computers to Start displaying the Screen Saver / Locker after 10 minutes, and then to turn the Display Off after 30 minutes of inactivity total.

If the screen has been turned off as the Lid Close Action, this does not turn on the Screen Saver. Thus, with such settings, it can be that KDE next turns the Screen Saver, and thus the display, back On after 10 minutes, to display a Screen Saver which nobody ever sees. And then after another 20 minutes of that, these KDE settings should cause the display to turn off a second time.

In the meantime the WiFi antenna would receive no incoming signal for 20 minutes, starting from 10 minutes after I had closed the lid.

This might sound very strange to some Windows users, but simply follows mechanistically from such settings.

So I am now experimenting, with setting the laptop Lid Close Action to be Turn the Screen Off. But then I am setting the Display Power Saving Off Delay, to be equal to the number of minutes, within which the Screen Saver will Turn On.

Hence, my new settings should never allow for the display actually to be on, while the lid is closed. And then we will see, whether this laptop seems to disappear off my LAN again…


(Edit 04/30/2016 : ) The affected laptop has now been able to stay visible on my LAN, with its lid closed, for 12 hours overnight, while previously, it used to vanish off my LAN within a few minutes of my closing the lid, regardless of what my software settings were.

So I am declaring this experiment a success.

And for the same reason, that I am linking the current posting, as relevant to This Earlier Posting.


BTW, In order to test this visibility, I have been using a 3rd-party Android file manager app, which is also particularly efficient as a share / LAN browser. As it happens, my router has been enthusiastic enough, to continue to register the laptop ‘Klystron’ as connected, after its signal was lost, and after I could no longer get data to and from it.

But this 3rd-part LAN-browsing, Android app, will show me honestly, that the laptop has quit the LAN, within a few moments of the laptop doing so, which the laptop has not done for more than 12 hours now.

Further, this 3rd-party LAN-browsing app is also sophisticated enough, to display the computer I use as my server (‘Phoenix’) twice, once with its real IP address, and a second time with the IP address of its OpenVPN presence. That makes this app the only software I presently have, that can even detect my VPN, from elsewhere on my physical LAN.


(Edit 05/01/2016 : ) My laptop has now stayed connected to my WiFi for more than 24 hours, and without any glitches at all, with its lid in the closed position. So again, the simple fact that its display is off now, 100% of the time the lid is closed, seems to have helped.


Print Friendly, PDF & Email