Using iwd for WiFi in Fedora

Fedora uses NetworkManager as the default for managing all the various different types of network. Underneath NetworkManager uses wpa_supplicant to connect to 802.11 based, AKA WiFi, wireless networks. There is an alternative called iwd which in a number of use cases works better, it also has the advantage that it offloads a bunch of things like crypto to the kernel interfaces which makes it smaller, and it’s under active development. iwd has a nice straight forward interface as well as being supported as an alternative NetworkManager so it just works in Fedora whether via nmcli or your chosen desktop environment.

So how do you make use of it in Fedora? Well it’s been packaged and supported for some time so it’s quite straight forward and there’s two ways to use it with NetworkManager. You can either swap it out for wpa_supplicant, or they can be installed side by side and you can change the NetworkManager default in a config to enable easy testing/swapping.

Option 1 (side by side):

sudo dnf install -y iwd
sudo cat >> /etc/NetworkManager/conf.d/iwd.conf << EOF
[device]
wifi.backend=iwd
EOF
sudo systemctl restart NetworkManager

Option 2 (swap):

sudo dnf swap -y wpa_supplicant iwd
sudo systemctl restart NetworkManager

You can now connect to WiFi networks a before with NetworkManager. Note it loses exciting configured WiFi networks.

Using nmcli to configure a static dual stack wired network interface

I recently managed to break the network on my VM that hosts this blog. Basically I removed the NetworkManager-initscripts-ifcfg-rh package because I don’t use the old style ifcfg configuration anywhere else and I had forgotten how long I’d had this VM. So I went into the web console, manually bought up the network with ip commands and reinstalled the package but it made no difference. Oh well! Time to just move it to the new config so I just worked out the nmcli options for all the bits in the old ifcfg. This VM network is nothing special, it’s basically dual IPv4/IPv6 interface with associated DNS.

Step 1: Show existing connections:

$ sudo nmcli c
NAME  UUID                                  TYPE      DEVICE 
eth0  a603bba7-fad8-3c71-9d4c-2cd5dc50e114  ethernet  eth0   

Step 2: Delete existing connection:

$ sudo nmcli c del a603bba7-fad8-3c71-9d4c-2cd5dc50e114

Step 3: Create a new connection (Note the IP addresses are random, the DNS servers are the Google public ones):

$ sudo nmcli c add type ethernet ifname eth0 con-name eth0 mac 80:00:00:ab:cd:ef ip4 192.168.10.6/24 gw4 192.168.10.1 ip6 fe80::b257:377c:e7b3:29ed/64 gw6 2A03:B0C0:0003:00D0:0000:0000:0000:0001 ipv4.dns "8.8.8.8 8.8.4.4" ipv6.dns "2001:4860:4860::8888 2001:4860:4860::8844"

Now the blog is back! The new connection is stored in /etc/NetworkManager/system-connections/eth0.nmconnection

Setting the wireless regulatory domain

Different regions around the world use slightly different frequencies for the various wireless interfaces available on your average Linux portable device such as WiFi, Bluetooth and other such interfaces. Overall they fit into larger categories such as 2.4Ghz, 5Ghz etc, but within each of these larger buckets countries have a subset of the frequencies, generally referred to as channels available. For example the 2.4Ghz range used by most WiFi and Bluetooth interfaces has potentially up to 14 channels available, the default is a generic “world” region which uses 11 channels that are available in all regions, but a lot of regions have 13 available for use, and some even have 14. The situation is similar on the 5Ghz range, and no doubt on the higher frequencies now becoming available too.

So to make best use of these while operating in the legal ranges for a country the regulatory domain needs to be set for the device. Linux handles this with three components, the kernel CRDA interface, a signed regulatory DB, which in Fedora is a package called wireless-regdb, but may also be called crda, and the iw tool. In some cases if an access point is using channels outside of the default “world” range you may not even be able to see/connect to the network.

There’s a two ways you can fix this. Firstly straight on the command line with the following command line options. The first shows you the current settings, the next sets the domain for the UK, but setting it this way isn’t persistent, but it’s useful for testing:

iw reg get
iw reg set GB

To make the setting persistent on every boot you just need to set a country in the /etc/sysconfig/regdomain file with a line that looks like this:

COUNTRY=GB

Of course use the code for your country of location based on the standard two letter country codes.

Documenting my various arm and IoT devices: quick overview

It’s been around ten years since I got my first arm single board computer, a Beagle-xM, which started me down the route of playing with Fedora on ARM and ultimately to my role in device edge/IoT at Red Hat. Shortly after that time I also moved into my current flat, almost ten years later I finally made the decision to move to a new place.

In the process of unpacking the contents of boxes from the flat into my new home office I thought I would document all my devices. This is mostly for my own reference, but I have little doubt others are interested from previous conversations. I’ve broken the list down into a few broad categories, mostly so the blog post isn’t unwieldy, there’s certainly cross overs between the categories, like some generations of the Raspberry Pi can run in either 32 or 64 bit mode, some Arm SBCs also have an integrated micro controller etc. For simplicity I’m putting those cross over devices in a single list, that of which they’re most capable, I’m also not putting devices on the list that aren’t easily able to run an open source OS such as Linux or Zephyr RTOS as I have numerous micro controllers/phones etc I can’t be bothered with and hence they’re not seen as useful for this list.

The lists, I will update with links as I post them, are going to be as follows:

  • Part one: Arm 64 bit devices (aarch64)
  • Part two: Arm 32 bit devices (ARMv7)
  • Part three: Micro controllers
  • Part four: x86 and other devices

Thoughts on Project Connected Home over IP (CHIP)

In late December 2019 Google, Amazon, Apple and a number of other companies announced Project Connected Home over IP. Like all Internet of Things I thought I would dig into it and see what it’s made up of.

First thoughts before I even began to dig were basically “well they got there eventually!” as I’ve long believed that for IoT in the home to be successful as a whole there needs to be a single set of open standards that all devices speak so that the things can intercommunicate…. you know, just like the internet! But like so many of these things the big companies always attempt to see if they can control the entire market first, then realise they need to “compromise” and work with the other players on standards, which is when the market starts to actually mature and consumers start to win out!

If you look at the project’s web site there’s, at least at the time of writing, 16 company logos on the page, of which around six or seven I would consider household names. A standard such as this was always going to happen. If you look at the “Home IoT Market” it’s a mish-mash of competing and incompatible standards, none of which really have a lead and some of the big names, such as Apple with their HomeKit interface (I refuse to use the term “standard”), have been struggling to get any real level of foot hold in the market. Some of the more popular off the shelf devices have been things like Samsung’s “SmartThings” which implement a number of different radios etc as bridge/gateway devices to make other things work together, which in and of itself speaks volumes. If the companies themselves didn’t get themselves sorted out it would have ended up in governments mandating something. In short the whole category is a big mess!

So reading through the FAQ and various bits in the media about it what does it appear to do? It puts IP over stuff! Shocking right!? To quote the FAQ:

The goal of the first specification release will be Wi-Fi, up to and including 802.11ax (aka Wi-Fi 6), that is 802.11a/b/g/n/ac/ax; Thread over 802.15.4-2006 at 2.4 GHz; and IP implementations for Bluetooth Low Energy, versions 4.1, 4.2, and 5.0 for the network and physical wireless protocols.

So the technologies they’re using are WiFi, no real shock there, although there’s no mention of Wi-Fi HaLow AKA 802.11ah but for home use that’s nothing of note. Next up in Bluetooth LE, 4.1 – 5.0, again no real surprises here, there’s already a standard for IP over Bluetooth LE/mesh in the form of 6LoWPAN, the same as used by Thread and vanilla 802.15.4, slightly interesting they mentioned explicitly 3 versions of BT-LE and just didn’t say BT-LE in general as all versions support IP. The final option mentioned was 802.15.4, the bit that I find particularly interesting here is that Zigbee Alliance was one of the four companies in the original announcement, 802.15.4 is an open radio standard used by Zigbee, Thread, 6LoWPAN directly and a number of other protocols, Zigbee has their own Zigbee IP standard, which competes with Thread and others yet Thread, originally out of Google/Nest is the chosen one. I’ve also found Thread to not really be a completely open standard like TCP/IP, as while there is the OpenThread implementation, you need to be a paying member of the Thread Group organisation to have it certified!

So what else does the project offer? They mention the following but note the term “may include”.:

This may include a proposed standard for lifecycle events such as provisioning/onboarding, removal, error recovery, and software update.

I feel that the lifecycle events they mention are actually extremely important here, and standards in this area are just as important as connectivity standards such as IP for layer 3. If you look at components such as provisioning/onboarding there’s fairly new standards evolving such as the Intel/Arm FIDO secure device onboarding collaboration which are still quite new so I suspect they’re going to wait and watch these before making a decision which is actively a good thing in my opinion if it means one less new standard!

Overall there’s currently nothing actually new on offer here in terms of standards, what is new is a number of large companies committing to focusing on a single Layer 3 connectivity protocol. There’s already widely available hardware across WiFi/Bluetooth/802.15.4 as well as standard IP implementations for them all. This should actively replace Zigbee, Z-Wave and a number of other proprietary Layer 2/3 protocols and should be straight forward for adoption as there’s not actually a lot for anyone else to do.

I feel this is a move in the right direction and will make life easier for a lot of third parties who want their products to work with “the big three of Apple/Google/Amazon”, the move to more open standards is obviously good, but overall there’s really nothing particularly new other than another mechanism for closed companies to work together. I don’t think it’ll ultimately make much difference in general to the open source community as those companies will have their proprietary protocols/APIs sitting on top of IP, just like in other parts of the internet now. It’ll be interesting to see how open the process is once they release code and start to work on it.

Basically it’s a wait and watch so really I’m ¯\_(ツ)_/¯

Securing home networks and IoT for family at holiday time

Many people head home to family at some point over the holiday season, whether that be like today for Thanksgiving in the US, Christian Christmas at the end of December or one of the many and varied holidays. During that time most people that are technical will be asked to help fix or setup various computer or internet related devices that family members that are not so technical have acquired or broken since the last time they ventured home. For me it use to be the regular upgrade/replacement of the Virus Scan and anti malware software. These days it tends to be patching of phones and tablets and all sorts of other devices.

So what can the average technical person do to help minimise risks to family members, or stop them from being part of a large botnet sometime in the future, without making the technology hard or even impossible for family to use, or to minimise the calls throughout the year.

Router

The first port of call should always be the router. Often these just get stuffed in the corner, on a bookshelf or somewhere out of site and forgotten. From a security point of view they are the most important, they are the thing that primarily protects everything else as they’re the ingress/egress point of the network. So what to do and change on these devices:

  • Upgrade the firmware to the latest supported version, and configure it to auto-upgrade if it’s an option. If the last firmware is ancient consider moving to a third party firmware like LEDE Project or an OpenWRT dirivative. Worst case scenario throw it away and give them a new one as their present.
  • Change the admin password.
  • Change the SSID and set a reasonable password.
  • Ensure that the admin interface isn’t available on the WAN link, do a port scan.
  • Turn off port forwarding and UPnP on the router.
  • Switch it to OpenDNS (208.67.222.222 208.67.220.220), Google Public DNS (8.8.8.8 4.4.4.4), the new Quad9, or even better a combination of them so if one service goes down or disappears their internet will still work.

Phones and Tablets

Ensure the phone is set to auto install new OS firmware releases, also ensure that apps are set to auto update and that if the provider, such as Google Play, has a malware scan option in their App store ensure that’s turned on so it’ll clean up any apps that are discovered to be problematic.

TVs, Bluerays and other Media Players

It’s surprising the number of these devices that have network connections and never get updated. In some cases the network functionality is rarely, if ever used, I know I’ve pretty much disconnected all Blu-ray players from networks, turned off the wireless if it has it, and not ever had a complaint. Often it’s better to replace some of old network media devices with ones that are actively maintained such as Google Chromecast, Amazon Fire, Roku etc. It’s also worth checking if any of these devices have the ability to connect to via ad-hoc means and disable that to limit connections to only those that are on the standard home network.

Various IoT devices

IoT devices should generally, if at all possible, be isolated on their own network. This is easy if as part of securing the router you moved it to LEDE or something similar above, and configure it to have a strict deny-by-default policy. Check the existing network for devices that are connected to it. In some cases there may have been a device connected to it some time ago that have long been forgotten about and are no longer in use, or the manufacturer has ceased to exist and they’re just a compromise waiting to happen masquerading as an expensive paperweight. Those that are in use might not be using the IoT/network functionality, if so turn the network off. Those that remain obviously ensure they’re running the latest firmware, set for auto update, and if possible move them to the IoT network. In some cases it might be possible or better to replace connected lighting if it’s some terrible WiFi/Bluetooth globe with something like the IKEA TRÅDFRI system as it has reasonable security, is of good quality and is affordable. Also don’t forget to check for things like doorbells, locks, cameras and other such devices.

Conslusion

Securing the router and associated DNS is by far and large the most important thing to do, it will help mitigate/protect most of the other problems that loom on the inside. But disconnecting, throwing away, replacement of old devices is sometimes the easiest way to fix them too, or else isolating them.

Let me know what else people do, and what I missed.

Configuring HTTP/2 with Apache on Fedora

HTTP/2 is the new version of the well known HTTP protocol which has been at the venerable 1.1 since late last century. Version 2 was derived out of Google’s SPDY protocol and it’s a binary protocol over the text based 1.1. It introduces a bunch of improvements including reducing latency, multiplexing, and server push. There’s some useful improvements that will be great for things like apps that use WebSockets. The Apache httpd daemon has included complete support for HTTP/2 since the 2.4.17 release in the form of mod_http2.

First you should configure your site with SSL, I suggest using LetsEncrypt/certbot as documented in this Fedora Magazine article.

Then you need to make sure the module is loaded, at least in Fedora 25 this is enabled in /etc/httpd/conf.modules.d/00-base.conf by default:

LoadModule http2_module modules/mod_http2.so

Then you just need to enable the protocol in either the general configuration or in specific VirtualHost directives for specific sites:

# for a https server
Protocols h2 http/1.1

# for a http server
Protocols h2c http/1.1

Then it’s just a systemctl restart httpd to make the changes take effect.

To test whether you’re serving over HTTP/2 you can test using this HTTP/2 testing site or with the OpenSSL client (check for “ALPN protocol: h2” in the output) with the following command:

openssl s_client -alpn h2 -connect HOSTNAME:443

Note: HTTP/2 is not currently supported in the httpd shipped in RHEL.

Connect to a wireless network using command line nmcli

I use a lot of minimal installs on various ARM devices. They’re good because they’re quick to download and you can test most of the functionality of the device to ensure it’s working or to quickly test specific functionality but of course it doesn’t have a GUI to use the nice graphical tools which are useful to quickly connect to a wifi network or other things.

This where nmcli comes in handy to quickly do anything you can do with the GUI. To connect to a wireless network I do:

Check you can see the wireless NIC and that the radio is enabled (basically “Airplane” mode):

# nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 
# nmcli device
DEVICE  TYPE      STATE         CONNECTION 
wlan0   wifi      disconnected  --         
eth0    ethernet  unavailable   --         
lo      loopback  unmanaged     --         

Then to actually connect to a wireless AP:

# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect SSID-Name --ask

And that should be enough to get you connected. You can list the connection with nmcli connection and various other options. It’s pretty straight forward.

Cheap travel routers

In the past I’ve traveled for work, conferences and personal a lot. The first category has declined a little from the “travel all the time” I’ve done in the past since I’ve joined the release engineering team. When travelling regularly I have a collection of things I pack that make life easier and a little more pleasant.

On of these is a travel router, often hotels have wired but no wireless, or flaky wireless or you need to pay for more than one device (or even one device). I don’t have a high spec need but it must have the following:

  • Dual ethernet WAN/LAN (everyone knows I have lots of ARM devices!)
  • Wireless, doesn’t need to be massivly fast (hotel internet is the bottle neck!) but it does need to be stable
  • Standard power cables, either figure 8 plug with inbuilt switching PSU or micro USB
  • Small
  • Open source and hackable. Probably supportable with OpenWRT
  • Quick and easy to reconfigure

For a number of years the device I used was an Apple Airport Express as it was one of the few that met most of the above criteria. But then I stopped using a iPod touch which meant the last option was dead due to the lack of openness.

Time for a new one! I’ve been looking for a while, I almost went for the popular TP-Link WR703N router as it’s well supported in OpenWRT but it meant that I lost the extra wired network port.

Then I came across the NEXX WT3020. It comes in four official options all of which have 802.11n, dual 100Mb ethernet, and runs from a micro USB connector! All but the bottom end model have a USB port for 3G or storage. The top two models just seem to have SW options but no other HW. Perfect, it even has OpenWRT support! So I went with the WT3020H, all for around $20.

I ordered one, while I was awaiting for it to arrive the OpenWRT project released Chaos Calmer 15.05-rc1 which has a prebuilt image and literally in less than five minutes I’d reflashed it to OpenWRT via the standard web flash interface! I’ve not had time to test performance, throughput and features such as USB but it seems to work pretty well for a $20 router and all the core features I need are working and it’s in a form factor that is TINY and I don’t even need to take an extra power supply. I’d call that a WIN!