An Observation About Hardware Encryption

According to This Earlier Posting, and postings which came before, I was trying to pinpoint possibly two sources of faults, within the WiFi configuration of my Linux laptop ‘Klystron’. And one subject which I had touched upon, was that the 802.11n mode, even when fully enabled, does not seem to lead to any reliability issues, while OTOH, the actual performance was very poor, even with 4 CPU cores each working at 25%. And so a logical question which anybody would ask next would be, ‘Why the poor performance?’

This laptop uses a kernel module known as RTL8723BE as its driver, for a particular WiFi chipset, manufactured by Realtek.

The core problem, which other people on the Internet have already written about, I can best summarize from within my command-line console window, thus:


root@Klystron:/etc/modprobe.d# ls
dirk.conf             fbdev-extra-blacklist.conf  ndiswrapper.conf
dkms.conf             kvm-extra-blacklist.conf    nvidia-kernel-common.conf
extra-blacklist.conf  mdadm.conf                  rtl8723be.conf
fbdev-blacklist.conf  modesetting.conf
root@Klystron:/etc/modprobe.d# cat rtl8723be.conf
options rtl8723be fwlps=0 swlps=0
root@Klystron:/etc/modprobe.d# modinfo rtl8723be
filename:       /lib/modules/4.4.0-22-generic/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8723be/rtl8723be.ko
firmware:       rtlwifi/rtl8723befw.bin
description:    Realtek 8723BE 802.11n PCI wireless
license:        GPL
author:         Realtek WlanFAE <wlanfae@realtek.com>
author:         PageHe  <page_he@realsil.com.cn>
srcversion:     935DB8E91ADCC9A3C200D60
alias:          pci:v000010ECd0000B723sv*sd*bc*sc*i*
depends:        rtlwifi,rtl8723-common,rtl_pci,btcoexist,mac80211
intree:         Y
vermagic:       4.4.0-22-generic SMP mod_unload modversions
parm:           swenc:Set to 1 for software crypto (default 0)
(bool)
parm:           ips:Set to 0 to not use link power save (default 1)
(bool)
parm:           swlps:Set to 1 to use SW control power save (default 0)
(bool)
parm:           fwlps:Set to 1 to use FW control power save (default 1)
(bool)
parm:           msi:Set to 1 to use MSI interrupts mode (default 0)
(bool)
parm:           debug:Set debug level (0-5) (default 0) (int)
parm:           disable_watchdog:Set to 1 to disable the watchdog (default 0)
(bool)
root@Klystron:/etc/modprobe.d# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"BELL876"
Mode:Managed  Frequency:2.437 GHz  Access Point: xx:xx:xx:xx:xx:x
Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
Retry short limit:7   RTS thr=2347 B   Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70  Signal level=-40 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:48   Missed beacon:0

root@Klystron:/etc/modprobe.d#

There is an inconsistency here, concerning whether Hardware Encryption is in fact enabled or not. According to the ‘modinfo‘ command above, the parameter ‘swenc‘ defaults to ‘0’, which means that by default, encryption should take place in hardware, not in software. But according to the ‘iwconfig‘ data, both Power Management and Hardware Encryption are “Off”. In my personal settings, I only changed my choice for Power Management, turning that Off. I never touched the Hardware Encryption setting, believing that all the time, it would remain at its default, which is the logical inverse, of what the ‘software encryption’ setting should be.

Really, in order to obtain the full performance that 802.11n should offer, we need to have Hardware Encryption Enabled. And yet, this setting by itself, is logically separate from whether the 802.11n protocol is enabled. It is usually assumed though, that Hardware Encryption is enabled, for example for use on Android devices, etc.

So why would it not be enabled here?

Actually, there is a forum on which this exact question was asked:

Link To An External, Forum Site

I, too have ‘iwlist wlan0 scan‘ output, that confirms what my router settings state, which is that WPA2 encryption is required, as well as ‘802.11n‘ (required).

So what all this would seem to suggest, is that my WiFi driver is after all, stable as-is.

Dirk

 

Print Friendly, PDF & Email

Testing 802.11n

This posting is a follow-up to This Earlier Posting.

While I was testing 802.11n, I still had my router on “Mixed Mode”. In the meantime, the connection speed indicated on my laptop ‘Klystron’, using the command ‘iwconfig wlan0‘, had dropped from 72.2 mbps to 7.2 mbps. And while I could pull my hair out trying to figure this out, in reality the explanation for this seems simple. Since the previous posting, some WiFi device of mine established a regular, 802.11g connection, thereby dropping my whole network out of 802.11n mode.

I was able to solve this, by going back into my router settings, and instead of allowing b/g/n Automatic determination, set it to “N Only”. Doing so also rebooted my WiFi, and kicked all my devices off, so that everything needed to reconnect.

I suppose that one aspect of this which is not as pretty, is the fact that I generally need to reboot ‘Klystron’, and thus need to reload the kernel-module that runs its WiFi chipset, before that laptop indicates updated, 802.11n connectivity. But after doing that as well, I found that the command ‘iwconfig wlan0‘ indicated readiness to transfer data at 72.2 mbps again.

This time, I am on channel 6.

Having done so also implies, that if at some point in time I wanted to join my WiFi with an older device, that does not have this capability, that device will fail to connect.

The eventual result from this experimentation is, that I cannot find any practical way to achieve the data transfer speeds that 802.11n eventually permits, and this can be due to the fact that I am transferring data from and to an older, slower computer.

And while all this indicates performance issues, nothing so far indicates driver stability issues, on ‘Klystron’. I am still waiting for those to happen.

Dirk

 

Print Friendly, PDF & Email

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

 

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.

Dirk

 

Print Friendly, PDF & Email