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


To a newer version, still based on the same principles, gives improved performance:

# fixing

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"`"
    sleep 20; /etc/init.d/nmbd restart


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.



RTL8723BE Again

According to This Posting, when my laptop ‘Klystron’ had an older kernel version, it was suffering from a number of WiFi problems.

These problems seemed to be related to the RTL8723BE kernel module, a Linux implementation of the device driver, for a chip-set that seemed to run fine under Windows. Linux issues with this chip-set are famous.

More recently I have read some follow-up information, that makes the problems I was experiencing more easily explained.

Apparently, the Realtek chip-set in this laptop has not one but two points, at which an antenna wire can be connected – i.e., the possibility of connecting two antennae. The device-driver is supposed to detect which antenna has the stronger signal, and is supposed to switch to whichever one that is.

Apparently, my laptop was not made so cheaply, as only to have one antenna in fact, as some models do. This is evidenced by the fact that when I was running Windows on it, I was able to close and reopen the laptop lid at any time, and not risk losing the signal.

But what can happen with earlier versions of this kernel module under Linux, is that it fails to switch to the antenna with the stronger signal in real-time, instead making a static decision to stay with one of the antenna wires, at least after a connection has been established. And this would explain why, when I closed my laptop lid before, the kernel module would choose to stay with an antenna it had chosen, and one with the now-weaker signal.

On the side, what I now find is that since I have been upgraded to kernel version ‘4.4.0-30-generic‘, the kernel module and its WiFi service seem to have become very stable, until I put the laptop into Suspend Mode. When I Resume from RAM after that, apparently the kernel module receives some amount of corruption, so that it becomes unstable again. But this is not the only problem that laptop runs in to with Suspend to RAM, as also noted Here. Further, I still have this laptop set To suspend to RAM, whenever I close its lid. So there are still no sessions on this machine, with the lid closed, with the WiFi active, and with the laptop plugged in to AC power, as some users leave theirs.

Such a test might be a good thing, to see if the WiFi signal still fades like that, with the new kernel module. That test has not happened yet.



My Linux Laptop ‘Klystron’ And 802.11n Again

The Linux laptop I name ‘Klystron’ has been running in a single session, for 1 day and 7 hours so far, and with its lid in the open position, and remained connected to my WiFi in 802.11n mode.

Further, the last time there has been any real issue with this mode, occurred several days ago, and several reboots ago. On the rare occasion where the connection simply quit while in use, there were error messages in my ‘syslog‘, that vaguely pointed towards an 802.11n problem, according to my having Google-d those error messages.

But the behavior was introduced more recently, that simply closing the laptop lid would cause it to lose contact with my WiFi, without the actual connection being reported as ‘down’ by ‘Network Manager‘, and without resulting in any error messages. This situation would typically reverse itself, within seconds of my unlocking an active session, and would also reverse itself, without resulting in any Notifications. The laptop would simply never know, that overnight, there was no data received and transmitted over WiFi.

Similar but not identical results were obtained, while connected in 802.11g mode.

Given that nobody has ever asked me the question, of whether maybe my WiFi signal could already be weak where this laptop is situated, I would say that it remains unproven, that this setup has any 802.11n issues per se. And so, because I know how frustrating it can be to do so, I would also not encourage coders to start looking for errors very carefully, which might not even exist in the software, or in the firmware.

You see I still have this peculiar notion, that there can be something impeding the efficiency of the actual WiFi antenna, which could account for most of the instability I have reported. And I also have this peculiar notion, that the performance of an antenna is based on wave dynamics, and not on the dynamics of Quantum-Mechanical particle representations, of radio signals.