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 https://bbs.archlinux.org/viewtopic.php?id=173487
case "$1" in
date +%s > /tmp/suspend.log
# 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 ‘
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.