Stabilizing my Realtek rtl8723be WiFi card under Linux.

The laptop of mine onto which I newly installed Kanotix / Spitfire, and that is named ‘Klystron’, happens to have a Realtek rtl8723be WiFi chip-set, which is known to have stability issues under Linux. I found that recently my own experience also ran into these issues.

If you feel that you are also having these issues, it is important that you first check, whether in fact you have the WiFi card in question. This can be done via an ‘lspci‘ command, or with

lsmod | grep rtl8723

I felt that I needed to apply a two-prong solution to my own problem.

The first thing which I did, was to create a file named


The only content of which was the line

options rtl8723be fwlps=0 swlps=0

This solution may solve the problem, of the WiFi dropping the connection, after periods of idle time.

There is something to watch out for. There are some sources on the Web, which state that we should try  the configuration line

options rtl8723be fwlps=N swlps=N

The problem with this method is, that for certain uses in programming, in particular in the language C, which is used for kernel modules, a numeric value may be expected in place of a Boolean value, and if in this case the module sees an ‘N’, this value will not be equal to zero, because the ASCII code for ‘N’ is not zero, and any other value than zero is taken to be True! So to make sure that the kernel module registers False, we need to put a ‘0’.

But I found that a second issue was affecting me, which was the fact that this WiFi setup has IPv6 enabled, but that my router does not tolerate IPv6. This may have been causing my laptop to get dropped from the WiFi, even as I was downloading software. In my dhcp configuration, I have added the DNS Server, which is the free Google DNS server, in addition to the auto-detected server. But will offer the system an IPv6 resolution of a domain name along with an IPv4 resolution, and in the case of WiFi, apparently Linux will use the IPv6, without detecting that this ability was not assigned by the Access Point.

And so I felt that I also needed to disable IPv6 system-wide on this laptop. The way to do that was to add the following lines to the file ‘/etc/sysctl.conf‘:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

And then ‘sysctl -p‘. After that, I also did

update-initramfs -u

This is a very sticky issue, in which different users have reported, that some of these solutions either do or do not work for them. One reason may be, that users are in fact reporting different issues without knowing it. I cannot be sure that this solution will remain 100% effective for myself, let alone for the reader. I just wanted to share my own experience with this. So far, my WiFi chipset is stable again.

(Edit 04/12/2016 : ) Just to prove to you, how uncertain the state of that WiFi chip-set is, even though I did change the parameters fed into this kernel module, it still happens that when I leave that laptop idling overnight, its WiFi goes into suspend mode. This happens in a way which the applications usually do not see, so that those applications still think they’re connected. However, my ‘Pidgin’ IRC Client gets disconnected.

And then, when I resume my session, ‘Pidgin’, which uses a ping timeout, did realize it was disconnected, and just reconnects seamlessly. And this latter part seems to happen, directly after I unlock my screen-saver, which seems to suggest that this is not being introduced by the Kernel Module, but rather by KDE, etc. I suppose it might introduce some level of confusion into the software, if the Kernel Module was to provide the same function again.

So who knows, which of my problems – if any – I may really have fixed?

Just checking my package manager, I see that ‘Pidgin’ has an available ‘Away-On-Lock’ plugin, which was not installed. Just this evening I installed and activated that, just to see whether I can override a behavior, which might have been set erroneously to ‘Offline-On-Lock’, while the plugin was not installed… By tomorrow, I should know.



I have now custom-compiled ‘gimp-gap’ on my laptop, Klystron.

Now that the laptop I name ‘Klystron’ has Linux on it, it is also a part of my ritual, that this machine is to receive all the software which I feel a posh Linux system should have. One piece of software in that category is ‘gimp‘, which has the plugin ‘gimp-gap‘.

But then we find that from the package manager, ‘gimp-gap‘ is missing several animation output options. And as I did recall, the solution to that problem is to custom-compile gimp-gap v2.6, to work with gimp v2.8. This requires may dependencies. It also requires the options

export LIBS='-lm'
./configure --prefix=/usr

The former ‘-lm’, linker option needs to be given on 64-bit Debian, in order to overcome the peculiar error message:

//lib/x86_64-linux-gnu/ error adding symbols dso missing from command line



An Observation about the UEFI FAT32 Partition

In This Posting, I remarked that I had wiped the laptop I named ‘Maverick’, and replaced its Windows 8.1 O/S with a UEFI-enabled Linux, resulting in a computer I now name ‘Klystron’. This is a healthy computer which has a long road ahead of it, including any software I need to install.

But before I wiped ‘Maverick’, I did have a look at it with the Linux partition management tool named ‘gparted’. I found that Maverick had numerous partitions, for which there was no drive letter, which it came shipped with from the seller.

Those original partitions included one, which was a FAT32, and which performed the same function as the FAT32 partition does, that is needed for a UEFI-capable Linux install. So there is no system-software reason, for which the BIOS would treat my FAT32 partition any differently, from how it treated the original one.

That partition has a subfolder, which contains an .EFI File, which is ultimately the boot-loader.

It is possible for these compiled, binary EFI Files to contain statically-linked EFI signatures. Only, because these signatures cannot be found loosely in some sort of bin, it also follows that if the signature in question forms a chain, such a cryptographic chain needs to be complete in itself, and must lead to its master key, which is white-listed by the BIOS.

(Edit : ) The practical consequence of this would have been, that If we wanted to set up dual-boot, it would be feasible after all, first to allow our Windows setup-disk partition the HD, but to tell this setup-disk only to use the space partially, leaving the rest unallocated. After Windows set itself up, the next step would have been, to set up Linux ourselves, and to allow Linux to avail itself of the FAT32 partition, which Windows left.

The reason I still did not go this route, was the fact that on Maverick, the Windows partition was already almost half in use. I do not think it would have been safe, to tell ‘gparted’ just to shrink one of its NTFS partitions, because there have been compatibility issues, between how Windows and Linux implement NTFS. It has happened to me in the past, that I told ‘gparted’ to shrink even an ‘ext4′ file system (that belonged to Linux), and that having done so left that file-system unusable.

So the NTFS partitions on Maverick had their final size, while using up most of my HD space. And so to make a dual-boot machine, would also have required a fresh install of Windows, which was out of reach for the moment.

(Edit : ) I am noticing some fog about the subject, of whether it is possible to find not only executable EFI Files, but also Keys, in this FAT32 partition, which is also referred to as the EFI System Partition, or “ESP”. The issue I read arises here:

Quoted Article

The main problem I see with this, is the idea that public keys can simply be dropped into this partition, without themselves needing to be signed by the Master Private Keys, making those self-signed. The idea that this exists, strikes me as a massive security hole in Secure Boot…

(Edit : ) It turns out that the world is not such a strange place after all. Reading further down in the above article, I found that the only purpose in storing the Keys in the FAT32 partition, the ‘ESP’, was to make them visible to the BIOS before the O/S has loaded, so that we can tell our BIOS to Clear the previous Keys, and then to Set new Keys.

So the firmware must be told the new keys after all… This makes more sense…