Getting IEEE 802.11s (mesh) and 802.11r (fast transition) working on some old hardware in OpenWRT 21.02.1

OpenWRT has got to be one of my favorite Linux distributions of all time. It is small, efficient, simple, and well-thought-out. I've been running OpenWRT (and LEDE, and OpenWRT) for a very long time on TP-Link hardware, which can often be scored off of eBay for $20 -- and even less -- at the Goodwill Store (imagine my incredible glee when I scored a WDR3500 for $6).

The TP-Link WDR4300, 3600, and 3500 all use Atheros system-on-chip and offer 802.11g/n and 802.11an, which, for my modest home use, has been satisfactory since 2012. What's really interesting is that OpenWRT *still* is still supported on these devices. 

Making a more "modern" network consisting of mesh networking and fast transitioning has been a challenge because of how many iterations the software has gone through. For some time, I have wanted to walk through the house and roam across APs with minimal service interruption. After tinkering, I finally have mostly everything working.

I will now dispel old Internet lore regarding these devices:

1. 802.11s mesh networking works "out of the box." You do NOT need to install wpad-mesh-wolfssl any more. However, on my hardware, 802.11s does NOT work with encryption. SAE encryption is supported in the LuCI UI, but when this is attempted, the devices refuse to talk to one another. Perhaps this will be fixed in a later version of OpenWRT.
   
   
2. 802.11r fast transition requires identical SSIDs and encryption on all APs you want to roam between, which should seem obvious. What is not obvious is that all APs must have the same user-specified mobility domain, and "Generate PMK locally" must be checked. Options involving PMK, R0 and R1 keys do not need to be specified and are automatically managed by OpenWRT. I have read documentation stating that mobility domains are automatically generated by OpenWRT but what I have found is that if they are not specified, then fast transition does not work correctly.
   
   
3. I have found that a lot of IoT devices do not enjoy dissociation on low acknowledgement at all. As soon as the AP dissociates them, they immediately re-associate. Even my Windows 10 laptop seems to do this. So I figured that I would disable this option (it is enabled by default). This seems to make things a little less bumpy for these low-cost devices.
   

Below, I have included /etc/config/wireless from my "gateway" AP which serves as the central point of access:

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac' # There will be some default here, don't change it 
	option htmode 'HT40'
	option channel '9'
	option cell_density '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0' # There will be some default here, don't change it
	option htmode 'HT40'
	option channel '36'
	option cell_density '0'
	option noscan '1'

config wifi-iface 'mesh'
	option ifname 'mesh0'
	option network 'mesh lan'
	option device 'radio1'
	option mode 'mesh'
	option mesh_id 'YourSSIDMesh'
	option key 'your_secret_key'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
	option encryption 'none' # maybe 'SAE' will work one day

config wifi-iface 'wifinet0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'YourSSID'
	option encryption 'psk2+ccmp'
	option key 'your_secret_key'
	option auth_cache '1'
	option skip_inactivity_poll '1'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option mobility_domain '3137' # four digits, same across all interfaces
	option max_inactivity '20'
	option disassoc_low_ack '0'

config wifi-iface 'wifinet1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'YourSSID'
	option encryption 'psk2+ccmp'
	option key 'your_secret_key'
	option auth_cache '1'
	option skip_inactivity_poll '1'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option mobility_domain '3137' # four digits, same across all interfaces
	option disassoc_low_ack '0'
	option max_inactivity '30' 

Similarly, the following is the configuration from a mesh "repeater" node.

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac' # There will be some default here, don't change it 
	option htmode 'HT40'
	option channel '3'
	option cell_density '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0' # There will be some default here, don't change it
	option htmode 'HT40'
	option channel '36'
	option noscan '1'
	option cell_density '0'

config wifi-iface 'mesh'
	option ifname 'mesh0'
	option network 'mesh lan'
	option device 'radio1'
	option mode 'mesh'
	option mesh_id 'YourSSIDMesh'
	option key 'your_secret_key'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
	option encryption 'none' # maybe 'SAE' will work one day

config wifi-iface 'wifinet0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'YourSSID'
	option encryption 'psk2+ccmp'
	option key 'your_secret_key'
	option auth_cache '1'
	option skip_inactivity_poll '1'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option mobility_domain '3137' # four digits, same across all interfaces
	option disassoc_low_ack '0'
	option max_inactivity '20'

config wifi-iface 'wifinet1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'YourSSID'
	option encryption 'psk2+ccmp'
	option key 'your_secret_key'
	option auth_cache '1'
	option skip_inactivity_poll '1'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option mobility_domain '3137' # four digits, same across all interfaces
	option disassoc_low_ack '0'
	option max_inactivity '20'


  

Installing an MSI (Windows Installer Package File) in Microsoft Windows without administrator privileges

Assuming you have an MSI file you need to install as a non-Administrator user, open up a `cmd` window. (Press Windows Key-R and type 'cmd' in the box.)

💡 Drag and drop files and folders into the `cmd` window from the Explorer and it will insert the full path to the file or folder (thereby saving a lot of typing).

Type (and/or  drag paths!):

msiexec.exe /i C:\Path\To\something.msi
INSTALLDIR=C:\Path\to\someplace\where\your\user\has\write\access\
MSIINSTALLPERUSER=1 ALLUSERS=2

Additional information:

➤ If the value of the ALLUSERS property is set to 2, the Windows Installer always resets the value of the ALLUSERS property to 1 and performs a per-machine installation or it resets the value of the ALLUSERS property to an empty string ("") and performs a per-user installation. The value ALLUSERS=2 enables the system to reset the value of ALLUSERS, and the installation context, dependent upon the user's privileges and the version of Windows.

➤ The MSIINSTALLPERUSER and the ALLUSERS properties can be set by the user at installation time, through the user interface or on a command line, to request that the Windows Installer install a dual-purpose package for the current user or all users of the computer. To use the MSIINSTALLPERUSER property, the value of the ALLUSERS property must be 2 and the package has to have been authored to be capable of installation into either the per-user or a per-machine context. For information about authoring a dual-purpose package, see Single Package Authoring. If the value of the ALLUSERS property does not equal 2, the value of the MSIINSTALLPERUSER property is ignored and has no effect on the installation. The value of MSIINSTALLPERUSER property is ignored when installing the package using Windows Installer 4.5 or earlier.

Serial device passthrough from Linux KVM host to guest operating system

Today's challenge was to run some archaic Windows software within a kernel virtual machine (KVM) with the end goal of programming radio equipment through a RS232 serial connection.

I own a programming cable that has a male USB-A connector on one end and a male RJ-45 connector that is plugged into the serial port of a Motorola CDM1550-LS+. This connector presents a Prolific PL2303 USB to serial chipset on the USB, which is handily recognized by Linux. I was then able to get this to show up as a normal serial port under KVM, but, unfortunately, virt-manager 3.2.0 doesn't provide this capability in the UI when adding serial hardware.

Therefore, XML editing must be enabled before making the appropriate addition to the hardware tree.

<serial type="dev">
  <source path="/dev/ttyUSB0"/>
  <target type="isa-serial" port="1">
    <model name="isa-serial"/>
  </target>
  <alias name="serial1"/>
</serial>

Thanks, virt-manager, but where's "Pass-through serial device (dev)"

Fixing fontconfig for proper rendering of Microsoft fonts

This post is more of a reminder / howto to *me* and is lifted from stefan.angrick's blog.

This, in particular, applies to Cambria and Calibri.

If it doesn't already exist, create a file fonts.conf in the directory ~/.config/fontconfig/  That file will need to contain the following content:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="embeddedbitmap" mode="assign">
      <bool>false</bool>
    </edit>
  </match>
</fontconfig>

The *actual* way of getting CUPSD to share printers

Although modern cupsd documentation describes a couple of simple steps that should theoretically enable sharing of printers on your system, one critical component is missing.

Documentation on cups.org suggests using cupsctl and lpadmin to enable sharing of a printer; this is all fine and good:

cupsctl --share-printers
lpadmin -p printer -o printer-is-shared=true

Inside of the default cupsd.conf there is a section

  Allow @LOCAL
  Order deny,allow

You need to add the Allow @LOCAL line in order to enable sharing from local subnets, which is probably the most common user case.

Afterward, restart the cups daemon.

A better formatted version of the clinically useful depression outcome scale (CUDOS)