My Laptop ‘Klystron’ and WiFi Again

Just to summarize.

The laptop I name ‘Klystron’ has as one of its problems, that when I simply close the lid, the WiFi looses its connectivity, even though no error messages are displayed, and even though its GUI does not indicate that a new connection ever needed to be negotiated with my router. Yet, when I open the lid, this connectivity – i.e. signal – is reestablished immediately.

Previously, my router was set for 802.11 b/g/n mode, Automatic, and the ‘N Mode’ could not be realized, because my Guest Network was set to a simpler form of encryption than WPA2. At one point in time, I set the Guest Network to WPA2 encryption in a way unified with the main network, and this enabled 802.11n mode for the first time.

Also, I had some success in maintaining the connectivity of the laptop with its lid closed, just by changing the screensaver settings, so that its display was off, 100% of the time the lid was closed.

But then what I discovered, was that the speed with which this laptop was connected, dropped from 802.11n speed to 802.11 b/g speeds, because I had closed the lid.

Because I know that to have a single device on the WiFi that is not at 802.11n speeds, will reduce the connection speed of all my wireless devices to b/g speeds, I next set my router to ‘802.11n mode only’.

This ensured that Klystron was connected at 802.11n speeds again.

But it also brought back the behavior, that this laptop will lose its connectivity, whenever I just close its lid.

This is not due to any power-saving modes being enabled.


 

A while back, when I set up this laptop for the first time, there was the sporadic behavior, that it could lose its connection while I was busy downloading, with the lid up of course. This problem has since disappeared, but may have gone away for two reasons:

  1. I have undergone a number of kernel updates. Those kernel updates may have improved the stability of the hardware encryption of my WiFi chipset, which to the best of my knowledge is On.
  2. I have disabled any use that the laptop may make of IPv6, when connecting to this one router.

Either way, the chipset seems to be stable now. My kernel version is ‘4.4.0-22-generic‘.

And while I could set my router back to b/g/n Automatic mode, for the moment I am keeping my eye on the fact, that one slow device, or one laptop with its lid closed, would also drop the speed of my other devices – including my phone, my tablet, and my Sony Web-enabled Blu-Ray player. And so I am keeping my router set to ‘N Only’ for now. ‘Klystron’ will simply have to remain without a WiFi capability, while its lid is closed.

Dirk

 

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

 

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

 

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.

Dirk