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

 

One main reason for Choosing Kanotix

A question which many people have asked me, was ‘What is the advantage of choosing Kanotix, over choosing just any generic Debian / Linux OS?’

And an important area in Linux, is hardware recognition. We tend to appreciate it, if we can install a Linux system with little or no mess. And Kanotix users are of the variety, who want to be able to plug in all the latest hardware, and just have it play.

Kanotix does not always ship with the generic, stock Debian kernel, but with a special Kanotix kernel build, that has all the latest drivers in-tree. And it is a bit of a joke which we sometimes make, that even though Windows introduced the concept first, in many cases, Linux can be more plug-and-play than Windows is.

This is especially true for Kanotix.

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