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.



Some Thoughts about Laptop WiFi Antennae






























So I am declaring this experiment a success.









The problem ‘Klystron’ has with WiFi, Must Be A Hardware Problem.

It would seem that the laptop I name ‘Klystron’, is befallen by not one but two WiFi problems, which made it hard to identify either of them.

The main problem I was trying to get a handle on as late as This Posting, could be described as having a WiFi status that seems active to programs running on the affected laptop, but which causes that laptop to seem to lose its connectivity with the rest of my LAN, as seen from the LAN. I can verify that within seconds. It seems to take place, whenever I just close the lid.

The previous posting combined this observation, with the fact that I had set the Lid Close Behavior to Lock the Screen, to suggest that maybe the Screen Locking function built-in to KDE, was triggering this situation somehow.

But what I have now done, is to change the Lid Close Behavior to Turn the Screen Off, which simply causes the backlight of the screen to go dark. And just as before, closing the lid causes the same condition. What this rules out, is that the problem was caused by the KDE Lock Screen function per se. Further, KDE can be told to lock its screen, just with <Ctrl>+<Alt>+L. If I enter that key-combination and keep the lid open, ‘Klystron’ stays visible to the rest of my LAN, and its WiFi appears unfettered.

Now, what can sidetrack this, is the fact that a second type of malfunction will sometimes set in, which actually causes its WiFi to seem to log off, and which requires that I reconnect. One reason for which I need to reconnect, is the fact that my WiFi passphrase is stored on the laptop in a user directory, but as part of the KDE-Wallet system, that keeps such information encrypted with another password.

Hence, whenever I want the WiFi to reconnect for any reason, I must first unlock my KDE-Wallet, so that the Network Manager can be given my WiFi passphrase, to reconnect.

It is not clear what causes the initial disconnection though. A part of me thinks this could be due to misuse of my laptop on my LAN, of IPv6 addresses. But another part of me thinks this could be due to dodgy support of 802.11n within Linux drivers.

What I do know is that this second problem sets in much less often than the first.

Also, it is possible that closing the lid does not physically sever any type of antenna-connection, but may rather change the geometry of the antenna wave patterns, so that the signal strength may just go way down. This may be confirmed at some later point in time, when I try moving the laptop to a different location, relative to my router. I just find the thought sad, that there might be some sort of more-serious, hardware issue with the WiFi, since hardware issues are finally harder to solve than software issues.



Understanding The Intricacies Of KDE Logic

In This Posting, I was describing a problem with my Linux laptop named ‘Klystron’, in which the laptop would take itself off my WiFi, apparently every time I closed the lid.

In the short term, there was a solution to this problem. I was able to go into my KDE Power Management Settings, where I had set the action on closing the lid to “Lock Screen”, and I was able to change this setting to “Do Nothing”. The suspicion had never occurred to me, that there could be two distinct behaviors:

1) After (x) minutes, the screensaver can come on, and if the attempt is made to interrupt the screensaver after (y) additional seconds, that screensaver can ask the user for his password.

2) The user can ask KDE to “Lock The Screen”.

According to the way KDE works, (1) and (2) are as different as Night and Day. So apparently, Locking The Screen is also supposed to mean, Disconnect From WiFi. But the screensaver asking the user for his password to stop, does not mean Disconnecting The WiFi.

Live and Learn.

And actually, one main reason for which I do close the lid usually, is the fact that the laptop is more protected from dust etc., with the lid closed.


(Edit : ) This laptop setup uses Network Manager. So just this afternoon I left-clicked on the Network Manager icon while connected to my home WiFi, and then drilled deeper into its GUI, to adjust which settings would be displayed as additional information about the network I am connected to. Network Manager is somewhat flexible in this GUI layout adjustment, but does not really allow settings to be fine-tuned in the same way.

Some KDE setups use ‘WICD‘ instead of ‘Network manager‘.

What I saw, was that there was no specific parameter to display, for whether a WiFi network should disconnect, on locking the desktop.

The only relevant WiFi-related detail I was able to add to the display, was “WiFi Band”, which could plausibly have complemented “WiFi Security”, which was already included. For my home access point, WiFi Band now displays “b/g“, as a result of further troubleshooting steps of mine.

I have since disabled 802.11n from the kernel module…

This means in practice, according to my logic, that the behavior I described in this posting, of cutting out when I close the laptop lid, cannot be deliberate. If it was deliberate, it would also be something which can be configured differently. And thus, this can also not be due to any translation error.

Therefore, this is a bug, and one I can now reproduce any time I want to.