Better WIFI UX on the non-graphical installer

Things done in nixpkgs:

Things done upstream:

[nixos@nixos:~]$ nmcli d
wlp2s0  wifi      disconnected  --
lo      loopback  unmanaged     --

nixpkgs on  master [$!+] took 2s
❯ sudo ./result/bin/ifwifi scan
* 84:c9:c6:90:8d:29 	FamiliaAA       4          -58.00	Good
  44:48:b9:0d:ec:97 	Familia Ben\xc3\xadtez Anjel_PLUS 36         -78.00	Unreliable
  [ ... ]
  cc:d4:a1:4d:7c:97 	SANTOS_PLUS     40         -79.00	Unreliable

nixpkgs on  master [$!+] took 4s
❯ sudo ./result/bin/ifwifi connect
error: The following required arguments were not provided:
    --password <password>
    --ssid <ssid>

    ifwifi connect --interface <interface> --password <password> --ssid <ssid>

For more information try --help

cc @jonringer

I can’t really judge the pro/cons of NetworkManager on the installation device or if the proposed changes to NixOS need further tweaking. Please advice!

From the UX perspective, this should be a lot better though.

One other remaining question would be if ifwifi can connect to enterprise/school networks, seamlessly or if it would require some patching / upstream contributions.

It also looks like diacritics are messed up. Any advice? Is this a upstream fix, too? iw's fault it is.

Having network manager enabled by default, and telling users to use “nmtui” (network manager terminal user interface), that would be a good improvement and I assume it would be low effort.


Yeah, we can go for this. I’ll amend the PR.

What I do want in the longer term is a ifwiwi <TAB> like experience. But that depends currently on clap-rs finally implementing dynamic completion.

Once that’s in place (and I may be able to commit to implement, since I’m waiting for clap dynamic completion already for a while), we can switch and use nmtui as a fallback in complex cases.

It can’t configure EAP networks, but I hope that is fine for the installer.

1 Like

I recently added (21.11, I think) a decent way to configure wireless networks using the (preconfigured) wpa_supplicant daemon and wpa_cli.

It’s not super user friendly but it certainly better than editing /etc/wpa_supplicant.conf and connecting to a WPA enterprise network is no more difficult than the home network equivalent.

I’d be happy if you manage to improve the UX but the replacement should not make WPA enterprise worse, IMHO.

1 Like

The current method was the following, right? It wasn’t really complicated, we should provide something easier if anything.

wpa_passphrase SSID password > /tmp/somewhere.conf
wpa_supplicant -B -i wlp4s0 -c /tmp/somewhere.conf

The current method was the following, right?

You can still do that, but since 134030 the manual and the login screen recommends systemctl start wpa_supplicant and using wpa_cli.

Starting wpa_supplicant manually requires knowing the interface, in some cases the driver name and sacrificing a tty, which it’s pretty clearly worse. Generating the config with wpa_passphrase is simple enough but, again, no WPA2 enterprise nor WPA3 support.

The simplest way forward would be to replace wpa_cli with a less low-level tool, but I’m not aware of any.


One thing that is really scary about wpa_supplicant is:

# inside the wpa_cli repl
> <TAB>
[ 2 km of barely intelligible screenroll  ]

I think until I can improve the ifwifi experience, nmtui should really be our recommended way.

@hexa @rnhmjoj to clarify: nmtui does not support WPA2 Enterprise nor WPA3?

I think personal networks work, enterprise networks do not.

I just checked (was easy enough after all), actually it looks like it does:


Okidoki, so I pivoted the PR to make use of nmtui-connect (simple case) and nmtui (enterprise):

Yeah, for some reasons wpa_cli will spam you with the daemon log, but you can just ignore it. The commands are pretty low level but you can also scan networks, check the connection status.

nmtui does not support WPA2 Enterprise nor WPA3?

No no, I was talking about wpa_passphrase and the other tool. nmtui is probably the best UX but requires bringing NetworkManager into the minimal installer. I’m not sure why it was never done, I suppose the closure size is quite large.


The absolute closure is probably not even near the actual impact, though. What’s again the command sequence to check the diff of a typical minimal installer in nixpkgs?

I’m not sure, try something like

nix path-info -f nixos/release.nix iso_minimal.x86_64-linux
1 Like
nixpkgs on  mod-doc-ifwifi-installer [$]
❯ nix path-info --closure-size --human-readable -f nixos/release.nix iso_minimal.x86_64-linux
error: path '/nix/store/gxc939amrx95d3gahdfwv04k4r9qgkaq-nixos-minimal-22.11pre130979.gfedcba-x86_64-linux.iso' is not valid


You have to build it first:

nix build -f nixos/release.nix iso_minimal.x86_64-linux

then the same command but with path-info -rS should give you the closure size.

1 Like

Thanks, I ended up comparing the ISO:

200Mb is kind of heavy.

Another idea would be to patch wifi-rs to work with wpa_supplicant

Yeah, at the end of the day it’s 200MB for a small tui program: not exactly ideal. Remember that this is for the minimal installer.

We should probably be looking into connman and/or iwd too, maybe they have better tools for a smaller closure size.

iwctl seems pretty easy to use, I don’t know about WPA enterprise, though.

1 Like

ifwifi via wifiscanner uses iw already. I suspect that’s comparatively minimal.