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

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

Dirk

## Klystron, Kernel Update a Success

The laptop which I name ‘Klystron’, received a Kernel Update on July 7. This brought its kernel version to 4.4.0-30-generic as far as I can tell.

Prior to this update, one of the problems the laptop was still experiencing, was due to its Realtek WiFi chip-set, and the kernel module ‘RTL8723BE’. It had a malfunction in how it was connecting to my WiFi, which should have set in twice again, since July 7, according to earlier observations I had made. This bug had become quite predictable.

But since the latest kernel update, this malfunction has not been taking place anymore.

So I would say, that this kernel update was a huge, welcome success.

A separate question I have not yet answered, was whether its Suspend Behavior has also been corrected. This will be slightly more complicated for me to test, because as the above posting suggests, I had adapted a script, which seems to correct it. If the problem had been resolved in the kernel update, my script would simply not do anything. And the end result would remain, that the problem is not apparent.

In order to see whether the kernel update actually resolved that issue, I would first need to disable my script, and then try a few Suspend Cycles, since this problem was also not taking place with 100% consistency.

I have not yet committed myself to doing that.

Dirk

## Klystron Kernel Update

My Linux laptop named ‘Klystron‘ is still fully subscribed to the “Kanotix” repositories. As the reader may recall, Kanotix is a slightly customized version of Debian Linux, that is KDE-based, and that is maintained by a group of developer-experts who I trust implicitly.

Being subscribed to their specific repositories and configuration details has as one advantage, that periodic kernel updates are fed to me, via package manager.

As I came home from camping yesterday, on July 7, I also rebooted this laptop, and saw that indeed, a kernel update was being offered, which I immediately installed. So that laptop now has kernel version ‘4.4.0-30-generic‘, or so my /boot directory would seem to say.

One problem that I was experiencing with that laptop since before camping, was some subtle WiFi issue which I could no longer pinpoint. I had written, that its ability to use the hardware encryption offered by the (kernel module ‘RTL8723BE’) chip-set seemed to work fine. But there were some other problems with the WiFi.

I would like to be able to report, when and if that issue has been resolved completely. But since Klystron has only been running on kernel version 4.4.0-30-generic for one day, it is still far too soon to call out a victory. I will continue to observe the behavior of that laptop for the next little while, and give further comment on it later. So far its behavior looks good.

Dirk