Progress with the WiFi on Klystron

In This Earlier Posting, I had written that there were once stability issues, with the WiFi chip-set of my laptop, which I name ‘Klystron’.

Since then, there has been some updating of the kernel, and therefore also some updating of the in-tree kernel module, which operates the WiFi chip-set, and some updating of the firmware as well.

The way the behavior of the laptop has been since then is, that its WiFi connection finally seems stable, at 802.11n speeds and with H/W encryption, but that a rather odd behavior has cropped up, according to which the membership of that laptop in my Samba Workgroup, seems to fail overnight, consistently.

What I seem to decipher, is that this later malfunction is related to the fact that, like many Linux systems, ‘Klystron’ restarts some of its services periodically – nightly – including the ‘nmbd‘ Daemon, the Linux equivalent of the ‘Network Monitoring BIOS Daemon’, which emulates ‘NetBIOS‘. And something about the way the restart takes place is still not perfectly kosher. It seems to require I disconnect from the WiFi afterward, and simply reconnect, before the local laptop shows up as part of my Workgroup again. And yet, it remains fully possible to surf the Web, as well as just to connect directly to my Samba server and to browse it, using a predefined IP address…

But for the moment, there is no reason to suspect, that this has anything at all to do with the Firmware or the Kernel Module. And it has taken me some period of observation to reach that conclusion.

Dirk

 

Firmware Update Today

One subject which I have written about at length, is the apparent instability of the Realtek WiFi chipset, on my laptop named ‘Klystron’. If anything is likely to improve that, it would be a firmware update.

Well just today, a firmware update was installed, to ‘linux-firmware’ version 1.158, and this was also followed by a reboot.

After the reboot, I tried to test whether my 802.11n WiFi performance had improved. One main test which I did, was to transfer a 500MB file to the local laptop, from a Samba server on another computer on my LAN. And what I found, was some improvement in peak speed, to 2.0 Megabytes per second, corresponding to 16 mbps.

Before I could obtain that speed however, I first needed to restart the Samba server, which had been running on the originating computer since April 17. And this detail helps show, how speed limitations in transferring, may be due to numerous problems, other than the actual link quality of the WiFi client.

Dirk

 

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