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

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 ¯\_(ツ)_/¯

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.

Getting IoT kick started on Fedora

So a number of people have been discussing the Internet of Things on Fedora for some time. We now have a Fedora IoT mailing list where these discussions can be more centralised and directed.

So where and how do we get started here? I’m going to kick start some ideas here and repost it as a mail to the list so we can use it as a basis to start the discussion.

As I outlined in my Using Fedora as a base for the IoT revolution talk at Flock there’s a lot of use cases and components that make up a complete IoT stack. I think initially we should focus on two initial goals rather than biting off too much:

  • A IoT internet gateway device
  • A IoT sensors endpoint device

The general idea here is that both of the above would be a very minimal shared build, likely using atomic images to enable easy update/rollback with some specific components for each use case. Initially I suggest we focus on a single, or maybe a couple, of specific devices to limit the scope to something more achievable and to add features as we go.

IoT internet gateway device specs and features

  • Wired and/or wireless ethernet to provide internet connectivity
  • Bluetooth Smart (AKA LE)
  • Thread Stack support (6LoWPAN and friends)
  • 802.15.4 support
  • MQTT Broker support (not standard for a IoT GW but enables easier localised testing)
  • MQTT Client
  • Atomic support: updates, rollback etc
  • Works with both our endpoint below and other IoT OSes such as Contiki

IoT internet sensors endpoint specs and features

  • Wired or wireless ethernet IP support
  • Bluetooth Smart (AKA LE)
  • Equivalent to Thread Stack support (6LoWPAN and friends)
  • MQTT Broker support (not standard for a IoT GW but enables easier testing
  • MQTT Client
  • CoAP client
  • Atomic support: updates, rollback etc
  • Support for various inputs and outputs and sensors

I have no doubt missed a lot of details in the above use cases, it’s somewhere to start. I think we also need to look at tools like Node-RED and tools for managing the devices. IoT is a big topic, the idea is we need to get the conversation start somewhere. I’ll look forward to seeing you all on the list to do that.

FUDCon Tempe

Well its not long before I’ll be jumping on a plane to head over the pond to Tempe, Arizona to the latest and greatest FUDCon. This will be my forth FUDCon event. I always enjoy them. Its lots of fun catching up with friends and fellow contributors who’ll no doubt become friends. There’s always one thing I really don’t like about FUDCon…. its that there’s always too many awesome topics of discussion and sessions that I want to attend but they conflict with other sessions that I want to go to 🙂

So what do I want to discuss and see discussed at FUDCon Tempe? Well as per usual there’s lots so here’s a quick bullet list:

  • Fedora Mobility: How to take it forward and who wants to achieve what, and how we all go about it. As devices get smaller and every company and their dog release tablets I think mobile devices will become more key to Fedora. It also fits in very well with a number of the Fedora Board Long Term Goals in particular I think it fits well for the help people control their content and devices and the Access from anywhere strategy.
  • Sugar, OLPC and Sugar on a Stick: there’s going to be quite a few people from various OLPC and Sugar projects in attendance. Also the awesome adamw and the Fedora QA team is going to be there so there’s plans to extend the discussions we started at FUDCon Zurich. The OLPC project is arguably the largest deployment of devices based on Fedora. The OLPC OS that runs on their XO laptops is pretty close to a vanilla Fedora release and as the last of the XO kernel patches make it upstream you can run vanilla Fedora on them with few issues.
  • Fedora ARM and secondary architectures: dgilmore, ctyler, PaulW will (I think) all be there and Fedora ARM is really starting to amp up with their awesome work! This also crosses over somewhat into OLPC and is hand in hand with Fedora Mobility. I suspect the discussions will revolve around getting Fedora 14 and rawhide building, ARMv7 + hardfp builds and ensuring ARM becomes a solid secondary arch.
  • Cloud: This sort of stuff is part of what I do for my $dayjob and it interests me greatly! I just wish I had more time to contribute to the SIG.
  • MeeGo Netbook UX: yes, this was a big FAIL for Fedora 14 and I need to blog on this. Looking much better for Fedora 15. Watch this space!
  • IPv6. There’s been some interesting posts on using IPv6 with various ISPs with that other Linux based desktop OS. Why isn’t there the same for Fedora??
  • Friends: One of the big ones of the four F’s of Fedora.
  • There’s always lots of random hallway discussions.

There’s no doubt a number of things that I’ve missed. The other thought I have is what of my Mobility tech toys to bring along. I have my laptop obviously. My atom based netbook running MeeGo Netbook UX on rawhide, my XO 1.5 running Fedora 14, my Toshiba AC100 running Fedora ARM 13 but I don’t think I can pack 4 laptop/netbook devices 😛