An Observation About Hardware Encryption

According to This Earlier Posting, and postings which came before, I was trying to pinpoint possibly two sources of faults, within the WiFi configuration of my Linux laptop ‘Klystron’. And one subject which I had touched upon, was that the 802.11n mode, even when fully enabled, does not seem to lead to any reliability issues, while OTOH, the actual performance was very poor, even with 4 CPU cores each working at 25%. And so a logical question which anybody would ask next would be, ‘Why the poor performance?’

This laptop uses a kernel module known as RTL8723BE as its driver, for a particular WiFi chipset, manufactured by Realtek.

The core problem, which other people on the Internet have already written about, I can best summarize from within my command-line console window, thus:


root@Klystron:/etc/modprobe.d# ls
dirk.conf             fbdev-extra-blacklist.conf  ndiswrapper.conf
dkms.conf             kvm-extra-blacklist.conf    nvidia-kernel-common.conf
extra-blacklist.conf  mdadm.conf                  rtl8723be.conf
fbdev-blacklist.conf  modesetting.conf
root@Klystron:/etc/modprobe.d# cat rtl8723be.conf
options rtl8723be fwlps=0 swlps=0
root@Klystron:/etc/modprobe.d# modinfo rtl8723be
filename:       /lib/modules/4.4.0-22-generic/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8723be/rtl8723be.ko
firmware:       rtlwifi/rtl8723befw.bin
description:    Realtek 8723BE 802.11n PCI wireless
license:        GPL
author:         Realtek WlanFAE <wlanfae@realtek.com>
author:         PageHe  <page_he@realsil.com.cn>
srcversion:     935DB8E91ADCC9A3C200D60
alias:          pci:v000010ECd0000B723sv*sd*bc*sc*i*
depends:        rtlwifi,rtl8723-common,rtl_pci,btcoexist,mac80211
intree:         Y
vermagic:       4.4.0-22-generic SMP mod_unload modversions
parm:           swenc:Set to 1 for software crypto (default 0)
(bool)
parm:           ips:Set to 0 to not use link power save (default 1)
(bool)
parm:           swlps:Set to 1 to use SW control power save (default 0)
(bool)
parm:           fwlps:Set to 1 to use FW control power save (default 1)
(bool)
parm:           msi:Set to 1 to use MSI interrupts mode (default 0)
(bool)
parm:           debug:Set debug level (0-5) (default 0) (int)
parm:           disable_watchdog:Set to 1 to disable the watchdog (default 0)
(bool)
root@Klystron:/etc/modprobe.d# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"BELL876"
Mode:Managed  Frequency:2.437 GHz  Access Point: xx:xx:xx:xx:xx:x
Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
Retry short limit:7   RTS thr=2347 B   Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70  Signal level=-40 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:48   Missed beacon:0

root@Klystron:/etc/modprobe.d#

There is an inconsistency here, concerning whether Hardware Encryption is in fact enabled or not. According to the ‘modinfo‘ command above, the parameter ‘swenc‘ defaults to ‘0’, which means that by default, encryption should take place in hardware, not in software. But according to the ‘iwconfig‘ data, both Power Management and Hardware Encryption are “Off”. In my personal settings, I only changed my choice for Power Management, turning that Off. I never touched the Hardware Encryption setting, believing that all the time, it would remain at its default, which is the logical inverse, of what the ‘software encryption’ setting should be.

Really, in order to obtain the full performance that 802.11n should offer, we need to have Hardware Encryption Enabled. And yet, this setting by itself, is logically separate from whether the 802.11n protocol is enabled. It is usually assumed though, that Hardware Encryption is enabled, for example for use on Android devices, etc.

So why would it not be enabled here?

Actually, there is a forum on which this exact question was asked:

Link To An External, Forum Site

I, too have ‘iwlist wlan0 scan‘ output, that confirms what my router settings state, which is that WPA2 encryption is required, as well as ‘802.11n‘ (required).

So what all this would seem to suggest, is that my WiFi driver is after all, stable as-is.

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>