Bell Home Hub 2000: A Newly-Discovered Peeve

The router I have, that manages my LAN, as well as my WiFi, as well as my access to the WAN, is a “Bell Home Hub 2000″ router. Overall I’m very satisfied with this router, especially since I’ve been able to operate a Web-site, in spite of having this router, which does not provide loopback-capability. But just last night, I discovered a detail in how this router works, that disappointed me just a little.

I additionally have a Samsung Galaxy S6 phone, which can sometimes famously suffer from the problem of dropping its WiFi connection. Through a process of elimination, I found out that on my WiFi, this problem was caused, by some sort of issue with the 5GHz frequency-band.

WiFi today has the capability to operate at center-frequencies of either 2.4, or of 5 GHz. When the Samsung S6 sees that both versions of a WiFi access point are available, it will automatically try to connect to the 5GHz version, because doing so can offer the greatest connection speeds.

At the same time, this router does not allow, for the 2.4GHz access point, and the 5GHz access point, to have different SSIDs – which are the codes that people commonly use to identify an access point. In reality, by offering both the 2.4 and the 5GHz option to connect to the WiFi, my router is offering two different access points, that happen to have the same SSID.

Further, some advice given on the Internet is invalid, that states, users can force their Samsung S6 to connect using the 2.4GHz channel, out of their WiFi-settings, on the phone. With its present firmware, the Galaxy S6 has no such setting anywhere; its behavior is always automatic.

Continue reading Bell Home Hub 2000: A Newly-Discovered Peeve

Klystron Kernel Update Ends Suspend To RAM Experiments.

Only a few days ago, because that laptop is fully subscribed to Kanotix, the computer with the network name ‘Klystron’ received another kernel update, this time to version ‘4.4.0-34-generic‘, which for some reason also goes by the name ‘4.4.0-35Kanotix‘. This has had slightly sad, but also good consequences:

  1. I can no longer allow Klystron to Suspend To RAM, as by now, doing so sets the time-last-modified of the super-block of its FS into the future. In fact, after a recent reboot, the log-in manager also reported to me, that it was unable to enter the home directory of the main user. This gave me quite a shock, until I noticed, that I was still able to log in as the auxiliary user, after which a full reboot also fixed the super-block. What this means is that all my experiments with Suspend To RAM must end, including hoping that its WiFi chip-set will work after resuming. But, I had written several times, that the performance of the WiFi had improved, as long as I do not suspend the laptop…
  2. I can now focus on a user-configuration, by which closing the laptop lid locks it, but hopefully, the WiFi will stay connected. In hopes of improving the chances of that, in addition to the fact that support may have already been improved in the latest kernel versions, I have additionally set my router only to use a signal-width of 20MHz, i.e. not to use ‘channel bonding’. My logic behind that is, that higher speeds might look good, as long as the signal strength is good. But to cope with the possibly weaker signal of the lid being closed, a narrower WiFi signal-width, as set from the router, may help improve reliability.

But whether that pans out, only time will be able to tell. Even if it does not, simply having the WiFi disconnect and then reconnect, as I reopen the lid, should not be the end of the world.



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.