iwd: simplifying WiFi management [LWN.net]

By Jonathan Corbet
November 8, 2018

It has been nearly 13 years since Jeff Garzik proclaimed that Linux was "proving its superiority in the area of crappy wireless (WiFi) support". Happily, the situation has improved somewhat since then, but that doesn't mean that things can't get better yet. During the Embedded Linux Conference portion of the 2018 Open Source Summit Europe, Marcel Holtmann described the work being done to create iwd, a new system for configuring and managing WiFi connections. If this project has its way, future users will have little room for complaint about how WiFi works on Linux systems.

At the moment, Holtmann said, WiFi on Linux is far too complicated for users to deal with; it asks them for far too much information. Users have to contend with complicated configuration dialogs to provide details that, much of the time, the system should be able to figure out for itself. The situation is bad even on basic open networks, but it gets worse on corporate networks, where it is often not possible to create dialogs that can work right in all settings.

The problem comes down to the old wpa_supplicant daemon, which is a complex "Swiss army knife". It is "awesome work", he said, but it has two big problems. One is that the wpa_supplicant project doesn't make releases, with the result that nobody picks up the bug fixes that are made. And there are no usable APIs for controlling it, so users have to figure out everything themselves. It is a great tool, but few people have any idea of how to use it.

For some time, Holtmann and his collaborators thought that they could improve wpa_supplicant and turn it into a proper management daemon. But the upstream project does not want things to go that way; they have, he said, a lot more interest in producing a toolbox that can be used for tasks like testing new protocol specifications. This focus and the lack of proper releases mean that everybody ships their own version of wpa_supplicant, with unpleasant consequences. There is, for example, no Linux distribution support for the WPA3 protocol, even though wpa_supplicant has that support.

Developing iwd

Thus the decision was made to develop iwd instead. Its task is to manage all WiFi network connections used by a machine with a goal of only asking for information that it cannot figure out for itself — often only the network to connect to and the passphrase. It "remembers everything" so users do not need to repeat themselves. Iwd will be the only program that performs WiFi scanning on systems where it is running; that differs from systems using wpa_supplicant, where higher-level software must also scan for networks. With iwd, that work has all been pushed to a single level where good decisions can be made. Iwd is meant to support fast and reliable roaming; it can ask an access point for information about its neighbors and use that to maintain connectivity as the system moves.

An explicit decision has been made to not care about running on anything except Linux. The D-Bus API is used for communication, and the kernel's cryptographic interfaces are used for encryption functionality. Iwd, Holtmann claimed, has readable source code — another thing that wpa_supplicant lacks. There is a large battery of unit tests to go along with it. Version 0.1 was released in February, and 0.10 came out on October 20.

Iwd has been designed to deal with multiple clients from the outset. With wpa_supplicant, instead, only one client at a time can be handled, so systems have had to put a wrapper around it to make things work. On an iwd system, tools like ConnMan, iwctl, and user agents can all talk to the daemon directly, at the same time.

Support for iwd has been in ConnMan since version 1.34, and in NetworkManager since version 1.12. Integration with NetworkManager took some work, since it had to be convinced to not worry about many WiFi details and let iwd handle them. Iwd works well now for personal networks; support for enterprise networks is under development but not really ready yet. A number of distributions have packaged it, and there is "rough" support for ChromeOS as well.

Developing iwd required fixing a number of things in the kernel along the way. There had only been one user of the WiFi-control API so far, so a lot of things didn't work right, Holtmann said. Those problems have been fixed, and most of the patches are already in the mainline kernel.

Iwd offers a long list of features, starting with support for the station, ad hoc, and access-point modes. Modern features like SSID grouping and scanning with hidden SSIDs are supported; the four-way handshake for pairwise transient keys is coming soon. A lot of enterprise methods are being added, including support for the extensible authentication protocol (EAP). Configuration for EAP is not done through a graphical interface, though; it is too complex for users to be able to realistically deal with it, so it will instead use a configuration file provided by the network administrator. Making this work requires asymmetric_key keyring support in the kernel, which is set to be part of the 4.20 release. For extra security, this key can be stored in the Trusted Platform Module (TPM).

Toward 1.0

There are a number of features missing, but they are not expected to stop the 1.0 release from happening around the end of the year. These include pairwise master key caching, and an opportunistic wire encryption mode that prevents eavesdropping but doesn't bother with authenticating the other end. Support for the device provisioning protocol is in the works, as is WiFi P2P support, which is almost done. Work that can be expected in the 1.0 release includes an API review of the Embedded Linux Library and D-Bus interfaces.

Holtmann concluded by saying that iwd is not just about WiFi; it is also expected to work with Ethernet connections. Corporations are increasingly locking down their Ethernet ports, requiring authentication before they can be used. To work with such systems, iwd is gaining an Ethernet authentication daemon that can work with the TCP; initial support is already present.

The audience asked whether iwd would ever work without D-Bus; Holtmann replied in the negative. It would be better to optimize any inefficiencies out of D-Bus, he said, than to try to get iwd to work without it. When asked about supporting 802.11s mesh networks, he said that it was something that the project needed to do, but it will not happen right away; contributions are welcome, he added. The last question was about integration with systemd-networkd; he replied that things mostly just work now, but there are still some details to take care of.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to the event.]

Index entries for this article
Conference	Embedded Linux Conference Europe/2018
Conference	Open Source Summit Europe/2018

to post comments

iwd: simplifying WiFi management

Posted Nov 8, 2018 17:58 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

This all sounds pretty nice. Any plans for it to support fast connection tricks like OS X?

…or make a server-side version? hostapd has all these wpa_supplicant pain points after all - having WPA3 doesn't mean much if the other end is insecure.

iwd: simplifying WiFi management

Posted Nov 9, 2018 20:31 UTC (Fri) by linusw (subscriber, #40300) [Link]

OpenWRT would be an obvious candidate as the majority of the routers on the planet nowadays work with that as a baseline. However OpenWRT does not use D-Bus, instead it has its own marshalling stack called ubus. So at least it need to be adapted to ubus.
https://git.openwrt.org/project/ubus.git

iwd: simplifying WiFi management

Posted Nov 8, 2018 18:10 UTC (Thu) by GhePeU (subscriber, #56133) [Link] (22 responses)

A lot of enterprise methods are being added, including support for the extensible authentication protocol (EAP). Configuration for EAP is not done through a graphical interface, though; it is too complex for users to be able to realistically deal with it, so it will instead use a configuration file provided by the network administrator.

Wait, what? The users are supposed to ask the network administrators, who could very well refuse to support Linux, to provide a special config file and drop it in a specific path? That can't possibly be true, it would be a big user experience regression.

iwd: simplifying WiFi management

Posted Nov 8, 2018 19:11 UTC (Thu) by fartman (guest, #128226) [Link] (1 responses)

Correct, this is the biggest turnoff for me too (and why I am not switching to iwd until this is addressed).

iwd: simplifying WiFi management

Posted Nov 10, 2018 0:21 UTC (Sat) by ibukanov (subscriber, #3942) [Link]

How one is supposed to enter server or client certificates if not via a file? And if the file with certificate is necessary in any case, why not to add the rest of the config there?

For how bad the situation can be just look at OpenVPN config in NetworManager. It does allow to enter via GUI all parameters. But this is utterly useless. Doing nmcli import for a config file provided by sysadmin works so much better.

iwd: simplifying WiFi management

Posted Nov 8, 2018 19:27 UTC (Thu) by linuxlizard (subscriber, #105283) [Link]

Which EAP? There are dozens. But basic EAP-TTLS and EAP-PEAP are just a username+password, ignoring the certificate verification. The protocol uses MSCHAPv2 deep under the covers. But EAP-TLS is a horrible pain (certificates on both sides).

iwd: simplifying WiFi management

Posted Nov 8, 2018 19:40 UTC (Thu) by iabervon (subscriber, #722) [Link] (2 responses)

For "the network administrator", read "that coworker who got the network working with Linux". If you had individual questions, the official network administrators wouldn't answer them anyway, and you'd just have to enter each answer from your coworker's screen shot individually in a bunch of form fields.

iwd: simplifying WiFi management

Posted Nov 9, 2018 19:18 UTC (Fri) by naptastic (guest, #60139) [Link]

I didn't realize we work together.

iwd: simplifying WiFi management

Posted Nov 12, 2018 7:52 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

I see you also have met network administrators.

iwd: simplifying WiFi management

Posted Nov 8, 2018 21:04 UTC (Thu) by drag (guest, #31333) [Link] (5 responses)

I don't see much of a regression if any.

Trying to configure with a EAP-whatever GUI is a bewildering experience in the best of times with a bunch of options and choices that nobody can possibly know the correct answers for unless they configured the wifi network or have some other known good configuration to go off of.

iwd: simplifying WiFi management

Posted Nov 9, 2018 6:48 UTC (Fri) by abo (subscriber, #77288) [Link]

Where I work, the only supported way to connect a gnu/linux laptop to the wifi is by downloading and running a python script which asks for username and password and configures NetworkManager for you. A config file would definitely be an improvement.

iwd: simplifying WiFi management

Posted Nov 9, 2018 10:27 UTC (Fri) by grawity (subscriber, #80596) [Link] (2 responses)

EAP is unnecessarily flexible, true. But that doesn't prevent simple GUIs from being made. Look at iOS, or at Windows 10: they handle the most common case (EAP-PEAP/MSCHAPv2) with just two fields for username and password. Complex cases may of course continue to use a complex UI – but it should scale.

(Before you ask "what about the CA certificate": the aforementioned iOS and Win10 both implement 'remember-on-first-use', meanwhile Android 7+ adds a third field for domain verification. Both are secure options that don't require distributing a CA file.)

IMO, what really prevents easy GUIs from being made is the idea that numbers between 0 and ∞ don't exist; it's the thought that a program that only handles 95% of the use cases is 100% useless.

But I'm guilty of applying the same thought to iwd – as a sysadmin of one WPA-Enteprise network, I still catch myself thinking "If it cannot speak EAP, it's useless as a Wi-Fi daemon". No, it'll still be a good Wi-Fi daemon... just a pain in the ass to support.

(And watching the "integration" commits scroll by in NetworkManager's repository, all the "convincing to not worry about many WiFi details", it's difficult to call that integration any more than system("dhclient %s") counts as integration.)

iwd: simplifying WiFi management

Posted Nov 10, 2018 4:11 UTC (Sat) by marcH (subscriber, #57642) [Link]

> EAP is unnecessarily flexible, true. But that doesn't prevent simple GUIs from being made. Look at iOS, or at Windows 10: they handle the most common case (EAP-PEAP/MSCHAPv2) with just two fields for username and password. Complex cases may of course continue to use a complex UI – but it should scale.

Requiring a config file in such simple EAP cases would obviously be a regression. Even for moderately complex cases a config file is more prone to typos than a GUI.

Does it have to be a complex GUI vs none at all? "Make simple things simple and complex things possible" = a basic GUI for simple EAP cases and config file required only for more complex options.

Another option: a relatively independent config file generator GUI.

iwd: simplifying WiFi management

Posted Nov 11, 2018 22:17 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

"Before you ask "what about the CA certificate": the aforementioned iOS and Win10 both implement 'remember-on-first-use', meanwhile Android 7+ adds a third field for domain verification. Both are secure options that don't require distributing a CA file."

Whether TOFU counts as a "secure option" is very much up for debate. What's the UX like for the scenarios where: A bad guy impersonates the WiFi on first use; A good guy changes your WiFi systems incompetently; A bad guy impersonates the WiFi on subsequent use?

My guess is that the answers are: You can't realistically tell, cross your fingers that doesn't happen; A scary warning you can click past; The same scary warning you've learned to click past. If I'm right that's not actually security, it's just theatre.

Most of the 802.1x options seem to end up involving TLS. 20:20 Hindsight but probably what should have happened here is that the SSID was required to be an FQDN, then you could just leverage the Web PKI to ensure the AP can prove it owns this FQDN and have done with it. The Android design you've mentioned gets closest to this - except that "third field" is needed because Android has no way to tell whether mycorp-wireless-security.evil.example or mycorp.example is the right owner for the SSID "MyCorp Employees". So it's still very vulnerable to the ordinary non-technical user being tricked.

[Somewhat off-topic MSCHAPv2 rant]

It is impressive how much pointless acrobatics has been inserted beyond TLS though. EAP-PEAP/MSCHAPv2 is three whole extra layers that exist just to over-complicate a password authentication. I _think_ what Microsoft was going for here was to prove that their crazy unsalted password hashing scheme was a good idea, but the result is very bad indeed.

Ultimately in MSCHAPv2 the client will tell the server (which may be an imposter) three 64-bit values each of which is the result of a naive DES encryption using a different key but the same plaintext. The imposter can derive this plaintext. The three keys are: The first 56-bits of the user's NT password hash, the next 56-bits of the user's NT password hash, and then the remaining 16-bits of the user's NT password hash, padded with 40-bits of zeroes.

Even if the hypothetical user has a extraordinarily good password Moxie Marlinspike's 2012 DES cracker can give back the password-equivalent NT hash in about one day of an offline attack.

More likely the user has a merely ordinary password (e.g. TopGun86, 11 hits in Pwned Passwords), if so you're screwed immediately: Suppose we're interested in attacking users who've picked one of roughly 1 trillion (2^40) passwords. Before we start we pre-calculate the NT password hashes for these 1 trillion passwords, and we bucket them by the last 16-bits.

We stand up our bogus WiFi AP, we get a connection, it gives us their username, the data needed for the 64-bit plaintext and the three by 64-bit DES encryption results.

We do up to 2^16 DES operations to find the last 16-bits of the user's NT password hash, this takes a fraction of a second.

We now have a bucket containing on average 2^24 possible passwords. So we do somewhere in the region of 2^23 further DES operations to find out which is the right password.

Needless to say all this is possible in under a second on ordinary PC hardware.

Microsoft's solution here manages to be _tremendously_ complicated and yet it achieves no meaningful security benefit compared to just sending the AP your password in plaintext. Amazing.

iwd: simplifying WiFi management

Posted Nov 10, 2018 11:28 UTC (Sat) by ldarby (guest, #41318) [Link]

Once you know how, it's not bewildering. The correct tool is wpa_gui, it asks for username and password, and you're done. I've been using that for the past year to connect to my work's EAP wifi.

iwd: simplifying WiFi management

Posted Nov 8, 2018 21:49 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

On the other hand, if you can write an automatic translator from Apple iOS .mobileconfig to iwd config files, your sysadmin may be willing to just give you the iOS config file that you can then import.

iwd: simplifying WiFi management

Posted Nov 9, 2018 12:13 UTC (Fri) by boingo (guest, #127570) [Link]

💯!

Is there any reason *not* to use Apple's Over-the-Air Profile Delivery and Configuration?[1]

[1] https://developer.apple.com/library/archive/documentation...

iwd: simplifying WiFi management

Posted Nov 9, 2018 1:07 UTC (Fri) by k8to (guest, #15413) [Link]

Support for this flow seems nice. In practice in enterprise environments, it's all Linux users supporting each other, so if one manages to make a files that works and everyone can just use it, that's nice.

But eliminating any UI flow seems pretty unfortunate.

iwd: simplifying WiFi management

Posted Nov 9, 2018 11:33 UTC (Fri) by gdt (subscriber, #6284) [Link]

The experience with 'wireless configuration profile files' for MacOS administrators was not good. For example, a Eduroam identity provider might support both EAP-TTLS+PAP and EAP-PEAP+MS-CHAP but in practice only one of these might work at some odd site. Changing to a differing profile for the same SSID on the same access point used to be too hard for MacOS users -- it's not not a use case the MacOS designers foresaw. Because there are many such edge cases even MacOS has a GUI option these days.

There's a useful middle ground where a configuration file can pre-populate the GUI, so that users don't need to understand much of the wifi+eap arcana. Note that the number of Linux laptops is such a small proportion of even a university fleet that there is room for only one file format, so there's a lot to be said for getting the file format right the first time.

A GUI will always be desirable even for enterprise systems. There are some systems where networking is desirable but plugging in a USB to copy a profile file is problematic. And sometimes the situation comes down to the help desk reading magic over the phone -- there's no worse variant of this than instructing a user to use vi to type in a XML/JSON/YAML configuration file.

iwd: simplifying WiFi management

Posted Nov 9, 2018 15:48 UTC (Fri) by sciurus (guest, #58832) [Link] (4 responses)

Presumable previously the network administrators gave you the authentication information and you entered it into a GUI. Now they'll give it to you and you'll enter it into a configuration file. I can understand the motivation for doing this. Have you seen the dialog that NetworkManager pops up for one of these networks [0]? It's overwhelming, and basically impossible to fill out correctly unless you have exact instructions. That said, a simpler dialog that only asks for what is needed seems preferable to asking people to write a configuration file. I'm guessing higher-level tools like NetworkManager will add that.

[0] An example is https://kb.northwestern.edu/page.php?id=62255

iwd: simplifying WiFi management

Posted Nov 26, 2018 16:29 UTC (Mon) by pauly (subscriber, #8132) [Link] (3 responses)

> Have you seen the dialog that NetworkManager pops up for one of these networks [0]? It's overwhelming, and basically impossible to fill
> out correctly unless you have exact instructions. That said, a simpler dialog that only asks for what is needed seems preferable to asking
> people to write a configuration file. I'm guessing higher-level tools like NetworkManager will add that.
>
> [0] An example is https://kb.northwestern.edu/page.php?id=62255

WTF: THIS page is about how to get it wrong. They tell their users not to check the CA cert AND they use passwords on the client side. Combine this with with tialaramex' rant about MS-CHAPv2, and you have another university not even bothering to keep users safe from the evil twin. I'm an eduroam admin, and I can hardly believe that in 2018 some people don' t understand just how bad encryption without authentication is going to end up. eduroam is an interesting example, though. Since the SSID is the same everywhere, starting an attack
with a false AP is extremely simple. OTOH, there's now CAT on cat.eduroam.org. We're going to push their installers on 100K BYOD devices
until mid 2019 -- let's see how it works out. Sorry for this somewhat OT rant, but TLS has all the tools, you just have to use them.
That said, I admit that details may be tricky, though: https://github.com/GEANT/CAT-Android/issues/22

Martin

iwd: simplifying WiFi management

Posted Nov 26, 2018 17:42 UTC (Mon) by raven667 (guest, #5198) [Link] (2 responses)

Is this an issue with the certificate store on Ubuntu or with the NetworkManager UI, IIUC the 802.1x support on Windows and macOS either does the CA check or pins the certificate of the authentication provider on first use, most Universities around here are going to be using InCommon as the CA, so the exposure would be only on initial setup, after that the MS-CHAPv2 is happening inside a TLS session so its poor security properties are less important.

As far as using passwords instead of certificate auth for the client devices, the issue is one of support, in a University environment you are dealing mainly with BYOD, so you don't have administrative rights to the endpoint but need to support hundreds of thousands of endpoints any given semester, so either your helpdesk is walking tens of thousands of people through installing certificates on their devices (which they aren't going to be able to do), you use their existing username/password credentials or everyone uses the open guest wireless without encryption at all. For managing risk, it is probably more effective to deploy ubiquitous 2-factor auth, so a password disclosed by any event can't do much on its own.

EVIL Twin attack against Android and others

Posted Nov 27, 2018 13:58 UTC (Tue) by pauly (subscriber, #8132) [Link] (1 responses)

My big complaint is about clients not checking the cert at all, despite SSL/TLS libs and root certs fully present.
Actually, the problem got big with Android: 802.1X (or 802.11i) support was introduced with Android 2, but
the root certs against which to verify a server cert were buried in the Java cert store, inaccessible for the
normal user. A user would have to install the identical root cert again. Then, mobile devices are "always on",
acting on their own account all day. To make things worse, Android connects to any network whose SSID has
been configured previously -- without asking the user, without checking the server cert in any way.
So nowadays to attack users, you just set up a false AP a little off the real eduroam, but let it broadcast the
SSID. 90% of the Android devices will happily connect without their users even noticing, handing credentials
over to the false AP. It took us 45 minutes to launch this attack against ourselves using a Raspi. You don't
even have to setup the evil RADIUS server yourself, it's all readily available. Things only got better with Android 7
when the "system certficates" option was introduced. I think this is what you refer to as InCommon.
In contrast, a manually configured iOS will ask the user so it's a TOFU situation then.
CA Certificate: (None) simply means "Do not check". This is neither TOFU nor InCommon, but utter rubbish.
https://kb.northwestern.edu/page.php?id=62353 (Android instructions)
it is even more explicit:
CA Certificate: Do not validate

BTW: We use passwords, too, no client certs. But at least we _try_ to make our users use SSL in a sensible way.
(And there will be a big push when the German educational root CA expires in July 2019.)
Our main tool for this is CAT: https://github.com/GEANT/CAT.

Martin

EVIL Twin attack against Android and others

Posted Nov 27, 2018 15:28 UTC (Tue) by pauly (subscriber, #8132) [Link]

Sorry, I got "InCommon" wrong. This is a commercial CA, of course.
I meant "Any of the root certs in the system's store of trustworthy certs".
MP

iwd: simplifying WiFi management

Posted Nov 10, 2018 11:39 UTC (Sat) by ldarby (guest, #41318) [Link]

Agreed that's a massive usability regression. The sysadmins *are* the users of the network management software - who are they going to ask for help to get this config file to provide to end users? The fact it's not been made easy to configure means they probably will refuse to support it, unless they're massive linux fanboys, which most are not.

iwd: simplifying WiFi management

Posted Nov 8, 2018 19:34 UTC (Thu) by iabervon (subscriber, #722) [Link] (3 responses)

It seems like it would be worth supporting not having D-Bus if you don't need to tell the daemon anything dynamically. Particularly with the combination of wired ethernet (i.e., this machine will never roam to a different network) and enterprise (there's a config file rather than answers to individual questions), it would make sense to be able to replace D-Bus with just not having an API at all.

iwd: simplifying WiFi management

Posted Nov 8, 2018 20:05 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (2 responses)

I would guess that the API is used even just to tell NetworkManager "I am connected to WiFi", and then NM can start the DHCP client etc.

iwd: simplifying WiFi management

Posted Nov 9, 2018 12:32 UTC (Fri) by smcv (subscriber, #53363) [Link] (1 responses)

NetworkManager requires D-Bus. If you want a trivial static network configuration without using D-Bus for IPC, NetworkManager is not the tool you are looking for (systemd-networkd might be more suitable).

iwd: simplifying WiFi management

Posted Nov 9, 2018 13:23 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

Note that for simple or static setups NetworkManager provides a --configure-and-quit option that causes it to quit after it does its business. That is useful if you're used to configuring your network by writing NM keyfiles or ifcfg files.

Otherwise you're entirely right. systemd-networkd does a fine job without D-Bus and when you're using D-Bus it is capable of dropping off when unneeded, conserving resources in small configurations. And iproute & shell do a good job for static configurations anyway.

(disclaimer: a NetworkManager developer here)

iwd: simplifying WiFi management

Posted Nov 8, 2018 21:08 UTC (Thu) by andrewsh (subscriber, #71043) [Link] (3 responses)

> There is, for example, no Linux distribution support for the WPA3 protocol, even though wpa_supplicant has that support.

Debian experimental ships wpa_supplicant with WPA3 support.

iwd: simplifying WiFi management

Posted Nov 8, 2018 21:36 UTC (Thu) by xtifr (guest, #143) [Link] (2 responses)

Experimental isn't exactly a distribution, though. You can't "run Debian experimental" the way you can run stable or unstable or testing. It's just a collection of not-ready-for-prime-time packages, not a full not-ready-for-prime-time system.

I suppose you could call unstable+experimental a distro, but that seems like a bit of a stretch. (Not Stretch--that's currently stable.) :)

iwd: simplifying WiFi management

Posted Nov 9, 2018 15:04 UTC (Fri) by fghorow (subscriber, #5229) [Link] (1 responses)

Who's on First? ;-)

iwd: simplifying WiFi management

Posted Nov 9, 2018 16:05 UTC (Fri) by tome (guest, #3171) [Link]

That's the first thing you've said that's right.

iwd: simplifying WiFi management

Posted Nov 8, 2018 21:34 UTC (Thu) by mansr (guest, #85328) [Link] (5 responses)

The dbus dependency makes this entirely uninteresting to me.

iwd: simplifying WiFi management

Posted Nov 9, 2018 0:06 UTC (Fri) by Rudd-O (guest, #61155) [Link] (4 responses)

Should it have had a 100% custom protocol over UNIX sockets? Or perhaps be run as a Kubernetes-supervised container with an HTTP endpoint?

Cos those are your choices today.

iwd: simplifying WiFi management

Posted Nov 9, 2018 10:16 UTC (Fri) by metan (subscriber, #74107) [Link] (1 responses)

Maybe we just need netlink-like sockets that could be used between applications, but I guess that it's too late now, since dbus became de-facto standard.

iwd: simplifying WiFi management

Posted Nov 12, 2018 16:16 UTC (Mon) by cortana (subscriber, #24596) [Link]

I want to call functions, not fire packets off and deal with matching the replies to the requests I made... ;)

iwd: simplifying WiFi management

Posted Nov 13, 2018 12:13 UTC (Tue) by nhippi (subscriber, #34640) [Link]

Basing on d-bus rules out this code being used on Android. Kinda weird to design solutions that are only useful the niche of desktop Linux users, and ignore the wider user audiences.

iwd: simplifying WiFi management

Posted Nov 15, 2018 13:00 UTC (Thu) by mansr (guest, #85328) [Link]

Why does it need an IPC interface at all? The state of the network device is readily available directly from the kernel to anyone who wants to know.

iwd: simplifying WiFi management

Posted Nov 9, 2018 14:56 UTC (Fri) by bandrami (guest, #94229) [Link] (7 responses)

OpenBSD seems to have solved this better than anybody else:

ifconfig iwm0 nwid MyHomeWifi wpa wpakey My4w3someP4ssw0rd

That's it. The driver just does it.

iwd: simplifying WiFi management

Posted Nov 9, 2018 15:40 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (5 responses)

Most real world scenarios seem tu be much more complex than this. Wireless-enabled devices typically move around and the networks come and go. So do the devices themselves.

Implementing a reasonable and flexible enough policy for those cases is why do we have userspace daemons for this in Linux. I'm sure the OpenBSD approach works very well for static configurations, but so would a piece of wire.

iwd: simplifying WiFi management

Posted Nov 9, 2018 20:17 UTC (Fri) by Ranguvar (subscriber, #56734) [Link]

OpenBSD actually handles the device or network coming/going also.
You can simply add more lines for more network configurations, in order of priority.

iwd: simplifying WiFi management

Posted Nov 9, 2018 21:25 UTC (Fri) by bandrami (guest, #94229) [Link] (3 responses)

As Ranguvar noted, OpenBSD handles that as well. But honestly I have to ask how often is a laptop switching networks? In a typical day for me mine switches when it wakes up either at my office or at my apartment or at the coffee shop, and that's it. I grant a phone might pick up a lot of wireless networks at different times, but this is part of why I want a different OS for my laptop than for my phone.

iwd: simplifying WiFi management

Posted Nov 11, 2018 20:35 UTC (Sun) by tonyblackwell (guest, #43641) [Link]

"I have to ask how often is a laptop switching networks?"
Can be frequent - upstairs to downstairs at home, shopping centres... $200 11inch ASUS is small/light-enough to cart around almost like a phone. (Bought as a holiday don't-care-if-its-pinched item, encrypted).

iwd: simplifying WiFi management

Posted Nov 12, 2018 0:11 UTC (Mon) by Hattifnattar (guest, #93737) [Link]

THE coffee shop? Boy, I don't envy your lifestyle ;) Although in some places it's indeed "the".
Seriously, a laptop is a mobile device, and many of us use it as such and take it wherever we go.
Which includes different coffee shops, fastfood places, and even restaurants and parks :)
Many of us also travel, hop from one airport to another.
Some of us visit friends and even stay with them for a weekend or so, and sometimes work there.
For me there is not that much difference in connectivity requirements between my phone and my laptop.
Of course your mileage may vary...

iwd: simplifying WiFi management

Posted Nov 12, 2018 12:23 UTC (Mon) by farnz (subscriber, #17727) [Link]

In my case, it's switching networks to the point of needing the authentication process to run about once every 10 to 20 minutes, depending on my co-workers' network activity levels.

I'm at the office, in a spot almost exactly midway between two access points; signal strength and throughput from both APs is about the same in an empty office, and just below the roaming threshold. As a result, my laptop makes the decision to roam between APs when I'm idle based on airtime activity, and chooses the AP that looks least loaded at the time. If I didn't do that, I'd have randomly poor connectivity.

Better?

Posted Nov 10, 2018 12:11 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Note that this "better" solution actually just passes all the non-trivial cases to wpa_supplicant, as most Linux setups do today. So they've handled one particular case an OpenBSD developer cared about inside the kernel and left everything else to be handled the same way everybody else was doing it before. Not really comparable to iwd.

The specific trivial case they handle is WPA PSK, a pre-shared secret key. To once again quote U2, "A Secret is something you tell one other person". But not in WPA PSK, you write it on a Post It note and then surprise - this doesn't achieve any meaningful security because everybody knows the secret. So you should use 802.1x ("Enterprise mode") which isn't handled by OpenBSD's kernel in order to have actual user authentication. In WPA3 the PSK is replaced by a less crazy approach with a PAKE, (all participants agree keys by knowing the same password, but nobody reveals what the password is in the process) but in real systems lots of people are going to know that password.

In WPA and WPA2 people feel obliged to use PSK because if you don't a passive radio snoop gets to see all the traffic (!) with no effort. WPA3 finally fixes this so that without authenticating nodes will get encryption, RFC 8110 documents how. IMNSHO most people using a PSK today should not bother with a password at all on WPA3 since the real benefit (privacy) you care about is now available without a password:

"I can see Bob's Free Network, Bob's Private Network and Next Door Neighbour" "OK pick Bob's Free Network". Done.

Support for captive portals?

Posted Nov 10, 2018 9:22 UTC (Sat) by matthias (subscriber, #94967) [Link] (17 responses)

One thing that is really annoying me under Linux is the poor support for captive portals of public WiFis. On Android, when I connect to such a WiFi, I get a popup which allows me to sign in or just accept the usage conditions, before the connection is actually added to the system.

The same should be possible on Linux desktops. I think of the following procedure to connect to a WiFi:
1. Bring up the connection in a fresh network namespace.
2. Inside the new namespace:
(a) Test for working internet access
(b) If necessary: spawn a minimal browser with the captive portal
3. Once the new connection is working: add it to the default network namespace

Will this ever be supported under Linux? Cannot be that hard to implement. Of course, this will only work on desktops, where there is a GUI available, not on servers. But usually, I do not carry my server around to connect it to random public WiFis, anyway ;)

Support for captive portals?

Posted Nov 10, 2018 11:02 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (1 responses)

There's a captive portal detection by cooperation between NetworkManager and GNOME 3.14+. Isn't that enough?
(and NM can use iwd as a backend, to keep it on on-topic).

Support for captive portals?

Posted Nov 10, 2018 11:41 UTC (Sat) by matthias (subscriber, #94967) [Link]

Thanks for pointing this out. I was not aware of this and I will have a look whether I can use this outside of GNOME.

From what I have found on the web, this is still not the full solution. It seems like there is just some background testing on the active internet connection, whether there is a captive portal. If there is, I will get asked for credentials, etc. This is already a big improvement, still it is only one part of the solution. The other part would be to use network namespaces. Right now, I get a bunch of certificate warnings whenever I connect to a public WiFi, as Mail-Client, Browser, etc. are trying to use a not yet workable internet connection. Even worse, there is no error indication because the connections are silently rerouted to a different server (the captive portal). Instead they should either get some network unreachable error, or---if I am connected with the builtin LTE modem---use the existing and working connection until the new connection is in a workable state.

I am not sure exactly at which level this should get implemented. First I thought iwd would be the right point, but maybe NetworkManager is even better. NetworkManager should be able to fire up iwd in the new namespace and move the connection to the default namespace, once it is in a usable state. This would have the benefit, that it would also work for other kinds of connections.

Support for captive portals?

Posted Nov 11, 2018 9:55 UTC (Sun) by niner (guest, #26151) [Link]

KDE detects captive portals and offers to open them in a browser. In this case at least KDE applications also know that they are not yet online.

Support for captive portals?

Posted Nov 12, 2018 2:48 UTC (Mon) by ncm (guest, #165) [Link] (10 responses)

Dunno what you-all are using, but Firefox seems to pick up and handle "captive portal" logins without difficulty.

Another reason to abandon Chrome? As if we needed another.

Support for captive portals?

Posted Nov 12, 2018 7:24 UTC (Mon) by matthias (subscriber, #94967) [Link]

I stopped using Firefox when they removed support for vimperator. Right now I am using qutebrowser, which is indeed based on qtwebengine, i.e., the chromium engine. Back then, Firefox did not support captive portals. If it does now, this is very fine, but this is on the wrong level. I would really prefer support on the basic network plumbing level.

Why should every user application with networking support implement its own handling of captive portals, if it can be solved once and for all on the OS level like it is done on Android?

And how should a browser ever support using the configured and working LTE modem connection, when NetworkManager adds a new default route with a lower metric for the yet unusable WiFi connection?

The application level should see the WiFi connection, once it is usable, i.e., when there is internet connection. A link and an IP does not suffice, if routing stops at the portal.

Support for captive portals?

Posted Nov 12, 2018 8:33 UTC (Mon) by karkhaz (subscriber, #99844) [Link] (8 responses)

Sure, but that assumes that browsing the web is the first thing you do upon connecting to wifi. Meanwhile, your email syncing cronjob is failing silently. Or it's failing loudly, along with every other application that implements its own unique solution to captive portals all at the same time, and you have to dismiss each of their dialogue boxes. It's definitely not a good idea to expect this to be done on the application level, there only needs to be one agent responsible for dealing with captive portals.

I don't run a desktop environment, though, so I do probably the same thing as you: when I know that I've connected to a captive portal wifi network, I open a web browser and browse to a website that I know gets served over HTTP (no S) so that the router can hijack the connection and show me the portal page. This works with Firefox, Chrome, and indeed qutebrowser.

Support for captive portals?

Posted Nov 15, 2018 22:04 UTC (Thu) by kokada (subscriber, #92849) [Link] (7 responses)

> Sure, but that assumes that browsing the web is the first thing you do upon connecting to wifi.

And this is a fine assumption for 90% of the user cases. For the remaining 10% you probably can find a better solution yourself.

Just one example, a hook in your network manager (most of them supports one) that disabled all services depending on network.

Support for captive portals?

Posted Nov 15, 2018 22:20 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (6 responses)

I love systemd, but one thing that annoys me greatly is that `systemd --user` units cannot depend on root ones. So I can't make my email-syncing systemd timer depend on the network being up.

It's my personal machine, so eventually I will make the timer a root unit and write user `User=karkhaz` in the unit file to make it run as my user. But then it can't depend on my other user units, like checking to make sure that gpg can decrypt my passwords, and it just feels icky to be running all of my personal stuff through root systemd. The other alternative is to make a user "unit" that does nothing but poll root systemctl to see if the network is up, and fails when it's not, but that's so ugly that I can't bring myself to do it.

Support for captive portals?

Posted Nov 15, 2018 22:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> I love systemd, but one thing that annoys me greatly is that `systemd --user` units cannot depend on root ones. So I can't make my email-syncing systemd timer depend on the network being up.
It's understandable, user sessions run separately from the main daemon.

As a workaround, can't you use DBUS as a way to signal that the network is ready?

Support for captive portals?

Posted Nov 16, 2018 12:13 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

It's understandable, but it still feels like a buglet to me; from within a user session, I can make a connection out to the main daemon and wait for status events via CLI tools, and thus, if I needed this, I'd expect to be able to tell the user sessions to listen for events from the system daemon.

Note that this would be strictly one-way; user sessions can depend on units in the system session, but not vice-versa - the main daemon cannot be expected to listen for events from all user sessions.

Support for captive portals?

Posted Nov 16, 2018 16:32 UTC (Fri) by karkhaz (subscriber, #99844) [Link] (3 responses)

Exactly. It's definitely `understandable,' but I've always felt like user sessions are a second-class citizen for that reason, it's as if nobody is really meant to use them. Pretty much anything you do as a user depends on some aspect of "the system," whether it's the network being up, the home partition being mounted, etc. and it would be really nice to express this in user units.

I won't moan about it too much, since I lack the time to look into changing/fixing systemd to make this possible, and I'm basically very grateful for systemd. Thanks for the dbus suggestion, but my point more generally was that these things do seem like workarounds for something that I can't really perceive a good justification for (for the reason that farnz mentioned amongst others).

Support for captive portals?

Posted Nov 16, 2018 20:50 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

I've been using systemd to run my user session for years now (my dotfiles repo has commits dating to March 2013, but that branch was merged in March 2015 after I was happy with it on my home machine for a year or so). I think the main blocker at the time was "how do I write a unit that starts X well?". But that's solved now (except the "has to run as root" part since it apparently can't negotiate the permission handoff when systemd --user runs it). Granted, I don't worry about things like Internet connectivity blocking my user units. I just let them fail if they need Internet and can't get it (no different than "connected, but on a network that is disjoint") because it doesn't really matter. Most Internet-dependent units are triggered by timer units anyways and they'll catch up when they need to or they're listening on sockets and don't care either way.

I also rely on zero units in /lib/systemd/unit and instead ship everything in my dotfiles repo. This is because I have conventions that upstream doesn't provide like `environment.target` which is a bunch of oneshot units that do `systemctl --user set-environment` for things like TMUX_TMPDIR=%t/tmux and other variables which are session-wide. Other targets I have include mail.target, x11-wm.target, xorg.target, backup.target.

> home partition being mounted

Well, if you're reading the user's enabled unit files, it is already mounted. Personally, I use autofs for everything else and just let them fail if, e.g., my USB key containing secrets is not plugged in and unlocked.

Support for captive portals?

Posted Dec 7, 2018 3:09 UTC (Fri) by kneufeld (guest, #102718) [Link] (1 responses)

I think I would very much like to see your dotfiles repo, it sounds... fancy ;) But seriously, is it sanitized and available somewhere?

Thanks.

Support for captive portals?

Posted Dec 13, 2018 19:31 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

It is sanitized, but not publicly available at the moment. I have it on personal hosting, but since that isn't reachable from the wider Internet at the moment…. I'll look at getting it hosted somewhere public again.

Support for captive portals?

Posted Nov 12, 2018 13:53 UTC (Mon) by abo (subscriber, #77288) [Link] (1 responses)

This is the right way. Also, if you've configured the system to always route traffic through a VPN, then the real interface never even has to be visible outside of the sandbox.

Or you can reverse it and run all the applications in sandbox(es) and only make the network interfaces visible inside these app sandboxes once the network has been properly established.

Support for captive portals?

Posted Nov 13, 2018 17:03 UTC (Tue) by flussence (guest, #85566) [Link]

This is how I have my laptop configured — the entire X session runs in a netns with only a wireguard interface — and it works pretty well. There's plenty of rough edges with that arrangement that still need working out, but removing weirdness in the network state of programs that don't expect it is worth a little friction. Being able to roam without breaking TCP connections is a nice plus too.

Support for captive portals?

Posted Nov 13, 2018 9:04 UTC (Tue) by marcH (subscriber, #57642) [Link]

> One thing that is really annoying me under Linux is the poor support for captive portals of public WiFis. On Android, when I connect to such a WiFi, I get a popup which allows me to sign in or just accept the usage conditions, before the connection is actually added to the system.

BTW Android seems to have (unintentionally?) stopped supporting a number of captive portals when their redirection seems to trigger some https security check. Observed with Android Oreo. I haven't investigated and not narrowed it to what sort of portals, so apologies for being short on technical details - this just to mention life isn't always rosy on Android either.

iwd: simplifying WiFi management

Posted Nov 10, 2018 11:52 UTC (Sat) by ldarby (guest, #41318) [Link] (4 responses)

Overall this is really sad. With wpa_supplicant there is a body of working code that's mature and debugged. Let's just throw it out and start over because, why?

It sounds wpa_supplicant devs they just don't want responsibity for providing wifi on Linux, instead what's happened is their playground for "testing new protocol specifications" happened to be good enough (barely) for it to be used by everyone.

iwd: simplifying WiFi management

Posted Nov 11, 2018 15:39 UTC (Sun) by mageta (subscriber, #89696) [Link] (2 responses)

Maybe its also a bit due to lack of any real competition. Sounds to me from the article - I haven't really invested any time - that there is only really wpa_supplicant in the field right now. Much like before clang became a competition to gcc, which finally brought some more (end-)user-focus (i.e. better diagnostics for developer). Maybe the same will happen here.

iwd: simplifying WiFi management

Posted Nov 12, 2018 13:26 UTC (Mon) by hmh (subscriber, #3838) [Link] (1 responses)

Not if this new utility is end-user (station) focused, e.g. by being useless in AP mode and/or not supporting openwrt. Which is just fine, I am not complaining.

But it does mean that right now (afaik) there is no other possible choice for wireless infrastructure than wpa-supplicant, and it does not look that this is changing any time soon...

iwd: simplifying WiFi management

Posted Nov 26, 2018 14:45 UTC (Mon) by Jonno (guest, #49613) [Link]

> Not if this new utility is end-user (station) focused, e.g. by being useless in AP mode and/or [...]

From the article:

> Iwd offers a long list of features, starting with support for the station, ad hoc, and access-point modes.

iwd: simplifying WiFi management

Posted Nov 24, 2018 22:55 UTC (Sat) by dirtyepic (guest, #30178) [Link]

Yeah when the only provider of an essential service has no interest in supporting their userbase, improving their code, or even making releases, I'm not breaking out the violin. The only sad thing is it took this long.

low-level user questions and ifupdown

Posted Nov 13, 2018 20:13 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

I’m wondering:

iwd seems to use a dæmon/client system. I would be using it with ifupdown, probably I’ll have to write the integration myself. I’m scripting around ifupdown for WLAN currently anyway. So, is iwctl scriptable?

Also, how does iwctl communicate with iwd? It depends on dbus, yet it (at least its Debian packaging) does not depend on dbus… so does it work without dbus at runtime? (That would be really awesome.)

Would I start iwd as system service, or when I start the first network connection? (I guess the former would be done by the packaging. I should look at the packaging in more detail, but I’m a bit short on time at the moment.)