## 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

/lib/systemd/system-sleep

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:


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

case "$1" in pre) date +%s > /tmp/suspend.log ;; post) 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"" fi /bin/sh -c "sleep 20; /etc/init.d/nmbd restart; /etc/init.d/smbd restart" & ;; *) ;; esac  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. Dirk ## Linux Support for RTL8723BE Almost Perfect Now In This Posting, I was continuing a long thread of comments, which began by saying, Linux support for the Realtek WiFi Chipset, that is served by the (linux) RTL8723BE kernel module, was dodgy at first. I was also experiencing problems with this, which required certain patches on my part. At the same time, my kernel has been upgraded to version ‘4.4.0-30-generic’, on the affected laptop I name ‘Klystron’, which means that kernel-crackers have also been updating the in-tree kernel modules, including the modules RTL8723BE… What I find is that by now, the behavior of that WiFi-chipset is stable. There was only one problem with it, which I had lastly been reporting, which stated that after the laptop resumes from Suspended-to-RAM, i.e. from a low-power mode that stops it in mid-session and continues to supply very small amounts of current to the DRAM – still performing refresh-cycles – the newly-connected WiFi was experiencing problems again. Well I found that changing a script which I had written, which was located in the directory /lib/systemd/system-sleep To a newer version, still based on the same principles, gives improved performance:  #!/bin/bash # # fixing https://bbs.archlinux.org/viewtopic.php?id=173487 case "$1" in
pre)
date +%s > /tmp/suspend.log
;;
post)
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""
fi
sleep 20; /etc/init.d/nmbd restart
;;
*)
;;
esac



The most important difference in the new script, is the unconditional execution of the script command “sleep 20“. My original intention was, that the script should wait for the network connection to be reestablished, before also restarting the ‘nmbd‘ daemon.

But, I observe that the behavior of the kernel, is not to create a new WiFi connection, until all the scripts located in ‘/lib/systemd/system-sleep‘, which run asynchronously, have exited. This means, that my WiFi also does not come back up, until this one script has finished, which will be more than 20 seconds after I Resume the laptop.

I do not believe strongly anymore, that the actual restart of the ‘nmbd‘ daemon accomplishes much.

But apparently, the simple fact that the WiFi connection waits for 20 seconds before being re-established, is what finally makes my WiFi stable – after a Resume From Standby !

This observation would also seem to confirm, that the last misbehavior of this chip-set was mainly due to the fact that it physically has two antennae attached, and that it makes a selection about which one to use, when the WiFi-connection is (re-)established. Apparently, the physical WiFi connection was not yet stable, ~half a second~ after the Resume. For which reason the Kernel Module has been choosing the weaker antenna, whereas after more than 20 seconds have elapsed, the correct antenna is chosen.

Dirk

## 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

## Downtime

This evening the Linux computer which I host this site on, named ‘Phoenix’, received an upgrade to over 60 packages in one shot, including a kernel update and firmware updates.

Even though Linux computers can often install upgrades without requiring a reboot, there are certain types of upgrades which even require a Linux machine to reboot afterward. This was one such upgrade.

Consequently, this blog, and my whole site, was affected from 19h15 until 19h45 this evening.

I apologize for any inconvenience.

Dirk