Meta

Tag: RTL8723BE

One of the observations I had written earlier, about the Linux laptop I name ‘Klystron’, illustrated in depth that it has issues with its Realtek chip-set, that provides it with both WiFi and Bluetooth connectivity, presumably providing both through the same physical antennae.

> BTW, have Linux developers ever discovered, that this chip is meant to have two antennae, which the laptop was built with, and that the drivers are supposed to switch back and forth, to whichever antenna was giving the best signal at any moment? I.e., that with the lid open, one antenna should be used, while with the lid closed, the second antenna should be used? I just thought I’d mention it as a segway… <

The Bluetooth functionality of this chip-set, on my Linux configuration, does not seem to work at all. And so something which I have done, which some people might find odd, is to buy a Bluetooth-dongle, to put that in a USB-port on the side, and then to pair my external mouse.

Actually, this has only worked on a second attempt, with a second BT dongle. I had given up on the first BT dongle, thinking that that dongle must somehow have been incompatible with the Bluetooth Stack in some way, failing consistently on both my Debian / Jessie / 8 systems. And I had erroneously come to that conclusion, even after the same, first dongle worked fine, on a Debian / Squeeze / 7 laptop.

The actual user-space software works fine, even telling me that the newer, better, $5 dongle detects the Realtek chip with its antenna only 20cm away (where it’s inside the attached laptop), and with my neighbor’s sound-bar detected upstairs from my flat… For another day.

I know that my ( “Logitech M557″ ) BT mouse works fine, because I can pair it easily with my tablet(s).

There is a bit of a trick, that will finally enable the Debian / Jessie laptop to pair with the same mouse. I need to use the GUI normally, to tell it to pair, while the mouse is in pairing mode, at which point the GUI shows activity for a few seconds, and the data-exchange-bars just seem to cease, and the mouse next stays in pairing mode, with its own blue LED still flashing rapidly, waiting to pair.

What seems to go wrong, is that after Linux has established a pairing, Linux fails to send a signal to the mouse, that it should switch from pairing-mode, to usage-mode, so that its LED extinguishes.

The way I found this out, was to wait after the data-exchange-bars in the Linux GUI vanish, where that mouse still has its Paired and Trusted icons, until the mouse ‘decides on its own’ to exit pairing mode, as if pairing has been unsuccessful – i.e. I waited for pairing-mode to time out on the mouse.

And then what followed, was that the mouse works, and that the GUI shows me that data is being exchanged steadily. After I have done this, the pairing is successful and apparently stable!

What this also tells me, is that I could have kept using the old dongle… But then again, the new dongle has USB 4, which the old one didn’t!

Yay!

BTW, This is a kind of BT mouse, that does not require we pair using a PIN. The GUI has a separate button for that.

On the laptop I name ‘Klystron’, I have kernel version ‘‘, and the misfortune of a WiFi chip-set that uses the kernel module ‘‘ with its companion kernel modules. Fortunately, I believe that it finally, fully stable!

I think that the most important detail on my part to getting this kernel module stable, was to add the file ‘‘ to contain the following code:

options rtl8723be fwlps=0
options rtl8723be swlps=0

Yet, as a series of blog postings already shows, it was not so quick and easy to obtain stability. One reason I think that my WiFi was failing on me recently, was my persistence in trying to put the laptop to Sleep, aka “Suspend To RAM”. This was never fully supported, and after Resuming from this sort of suspend mode, the WiFi would always be unstable. The only way I had to remedy this, was to change my user-level configuration, never to put the laptop to Sleep again.

Even with the WiFi supposedly stable in this way, the malfunction remains, that for any duration of time I close the laptop lid, the WiFi temporarily cuts off, which I think is a problem with the antenna. My solution: Leave the laptop idling, with its lid open. The result: Days and days of steady connection. Some small amount of dust on the laptop keyboard.

But there seemed to have been another problem with my WiFi specifically. The modem-router which I rent from Bell seems to have a specific policy. It sets itself to be the DNS server for my LAN, which downloads the IP addresses from its DNS parent. The WiFi router seems to have a zero-tolerance policy, if any computers try to bypass it as my DNS server. And this problem can be so strict, that even to have my LAN machines act as server, will cause problems and stability issues, which mimic hardware WiFi disconnection issues.

In my ‘‘, I needed to set

wins support = no
dns proxy = yes

Otherwise, the member servers would fail to see each other as Samba-connected, and finally lose their connection altogether.

Further, I had scripted the idea into my configuration files, to prepend IP address 8.8.8.8 as an additional DNS server into ‘‘ on boot-up, just hoping to obtain wider connectivity. But then one additional problem with that was, that this public DNS server would suggest IPv6 addresses in addition to IPv4, and that even though my user-level settings for the network said to ignore IPv6 addresses, a malfunction in the kernel – which has not bee remedied – would cause the WiFi client to try to request the IPv6 addresses anyway. My user-level settings were being ignored.

Thus, I think that getting rid of the 8.8.8.8 was instrumental in achieving stability. Since this router does not tolerate IPv6, and since it is now my only DNS server, there is no risk of IPv6 addresses ever getting mentioned on my LAN.

On that note: It is normal on a dual-stack machine, for each NIC to have an IPv4 as well as a local, “Link” IPv6 address. But I think that one aspect in which the behavior of Ethernet cards is different from WiFi, is that the Ethernet card will not try to use its IPv6 address, because that will recognize this is not a global address, which would need to be assigned by the router. It would only try to use its “link” IPv6, if it was to try to connect directly to another machine on my LAN. OTOH, It would seem that a WiFi chip-set will not recognize that its IPv6 is invalid, and will ask for “Global” IPv6 addresses.

This can be an embarrassment, if the router did not specify any, and if the router assumes that it is the only DNS server.

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:

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…

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.

One subject which I have commented on often, but which in recent months I have gotten little or no new information about, was the stability of the WiFi chip-set on my laptop ‘Klystron’, which is driven by the kernel modules known as ‘RTL8732BE’.

Since that posting, there have been 2 firmware updates to that laptop specifically. One, to version 1.159, and the next, to version 1.160.

What I found was that firmware version 1.159 actually seemed to make the WiFi very unstable again – a regression. But firmware version 1.160 seemed to make it stable again.

In the meantime, I have a script in directory

/lib/systemd/system-sleep

which is intended to deal with A Different Problem that laptop has, which was, that after resuming from sleep, the laptop system clock would seem to jump ahead exactly 68 hours. I had changed that script as an experiment. But now I have changed it back again, to:

I often did suspect that problems which I had specifically associated with the kernel module, may not in fact stem from the kernel module. On my LAN, I use a router which is not owned by me, but rather by my ISP, and that router has numerous settings – as well as its own Firmware flashing – under the control of my ISP rather than under my direct control.

This router is still useful to me, because I subscribe to “Bell Fibe” and get to watch TV through it, in 1920x1080i resolution, which I could not do, if I was to try switching to a router owned by me.

But many of the problems which Klystron has on my WiFi, may all be policy issues with this router. Since I cannot get deep into the router settings, I am left guessing as to what router policies the laptop may not be abiding by.

But what this can do is lead to Samba problems specifically, which seem to mimic general WiFi connectivity issues, but which are not really examples of that.