WiFi on Laptop named Klystron, RTL8723BE

One subject which I have commented on often, but which in recent months I have gotten little or no new information about, was the stability of the WiFi chip-set on my laptop ‘Klystron’, which is driven by the kernel modules known as ‘RTL8732BE’.

Here is an earlier posting on this subject.

Since that posting, there have been 2 firmware updates to that laptop specifically. One, to version 1.159, and the next, to version 1.160.

What I found was that firmware version 1.159 actually seemed to make the WiFi very unstable again – a regression. But firmware version 1.160 seemed to make it stable again.

In the meantime, I have a script in directory


which is intended to deal with A Different Problem that laptop has, which was, that after resuming from sleep, the laptop system clock would seem to jump ahead exactly 68 hours. I had changed that script as an experiment. But now I have changed it back again, to:

# fixing https://bbs.archlinux.org/viewtopic.php?id=173487

case "$1" in
    date +%s > /tmp/suspend.log
    was=`cat /tmp/suspend.log`
    now=`date +%s`
    # time shifts for 68 hours
    if [ $now -gt `expr $was + 244800` ]; then
      date -s "`date -R --date="68 hours ago"`"
    /bin/sh -c "sleep 20; /etc/init.d/nmbd restart; /etc/init.d/smbd restart" &

I often did suspect that problems which I had specifically associated with the kernel module, may not in fact stem from the kernel module. On my LAN, I use a router which is not owned by me, but rather by my ISP, and that router has numerous settings – as well as its own Firmware flashing – under the control of my ISP rather than under my direct control.

This router is still useful to me, because I subscribe to “Bell Fibe” and get to watch TV through it, in 1920x1080i resolution, which I could not do, if I was to try switching to a router owned by me.

But many of the problems which Klystron has on my WiFi, may all be policy issues with this router. Since I cannot get deep into the router settings, I am left guessing as to what router policies the laptop may not be abiding by.

But what this can do is lead to Samba problems specifically, which seem to mimic general WiFi connectivity issues, but which are not really examples of that.



New SAMBA Versions have some Conflict With the Old Ones.

Many desktop users are accustomed to the ability, to open “a network share” on a remote computer – acting as the LAN server – and then to be able to drag-and-drop, or to copy-and-paste files to and from a folder that represents this remote server, on our local client.

Under Linux, this has largely been duplicated.

But what many users are less-aware of, is the fact that this ability is commonly provided by a Microsoft protocol named ‘SMB’ or, ‘Server Message Block’.

Even though Linux has its own network drives via ‘NFS’, many Linux computers have been tuned to access the SMB protocol, through a Linux version of it named “Samba”. This is largely possible, because the first version of SMB, was not fully owned by Microsoft.

But the existence of Samba servers and clients under Linux, is what provides this ability, and in order to have Samba running, we also need to have elaborate configuration scripts.

What some Linux users may additionally not know, is that even if we have tweaked our ‘smb.conf‘ files to the maximum, our most up-to-date Samba versions will no longer be compatible with older Linux implementations.

On my LAN, I typically have 4 computers which are constantly connected:

  • Phoenix – This Linux server,
  • Mithral – A Powerful Windows client,
  • Walnut – An Ancient, Linux server which is by now obsolete,
  • Klystron – That powerful Linux laptop which has problems, sometimes difficult to distinguish if they are happening at the same time.


There is no specific reason why the behavior of ‘Walnut‘ should affect the other servers, even though this example is an ancient platform according to standards today.

And yet only recently I found, that Klystron could not connect to the share on Phoenix, even though Klystron seemed to have unrestricted access to the WAN. Furthermore, both Klystron and Walnut seemed to indicate, that there was no Workgroup to be found.

This problem was resolved, when I rebooted Walnut. Apparently, Walnut sometimes ‘thinks’ that it is supposed to act as the Workgroup Server, even though its smb.conf file says otherwise, and then it determines that certain clients are not a part of that Workgroup.

And then, after I just rebooted Walnut, Klystron and Phoenix were able to connect again. Sigh.



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.



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.