Network

Emanix does not ship a network control surface. NetworkManager is the mechanism — the consuming flake enables it and says almost nothing else about it — and the commands that drive it are ordinary shell commands run in a terminal.

That is a boundary rather than a gap. Which network a machine joins is one of the machine facts the distribution deliberately does not own; see Architecture.

1. Connect to a network

nmtui                         # full-screen; nothing to remember
nmcli device wifi list        # what is in range
nmcli device wifi connect <ssid> --ask

--ask prompts for the passphrase instead of taking it as an argument, where it would land in your shell history.

Ethernet needs none of this. Plug it in and it comes up.

1.1. The interface name is not wlan0

Predictable names still differ between machines: a radio may be wlp2s0 or wlp0s20f3 depending on where the card sits in the bus. So do not type an interface name copied from an example — ask for it: 

nmcli -t -f DEVICE,TYPE,STATE device status

nmtui never asks the question at all, which is why it is listed first.

1.2. Working from inside Emacs

There is nothing to configure, because there is no Emacs wifi command. The modeline shows whether you are online; connecting is a shell job. Open a terminal buffer and run nmtui there.

2. The modeline indicator

The top bar renders wifi✗ when the wireless interface is not up, and renders nothing when it is. It is an indicator only — it does not scan, connect, switch networks, or report which network you are on.

It reads operstate from sysfs for the interface it found once by probing sys/class/net/*/wireless. It used to shell out to nmcli for this — an exec, a D-Bus round trip and, under EWM, an activation token and a journal line every few seconds — to learn something one small local file already answers. The finer states nmcli reported (connecting, deactivating, unavailable) all render the same marker, because none of them is up.

3. Backends: the ISO is not an installed host

The installer ISO ships NetworkManager with the iwd backend, so iwctl works while you are installing. Installing does not reproduce that. NetworkManager is enabled by the consumer — the template sets networking.networkmanager.enable in configuration.nix — without choosing a backend, so an installed host runs with NixOS's default — wpa_supplicant on the machine this manual was written on — and iwctl, along with iw, is not installed at all.

The installation page therefore names iwctl as ISO advice. On an installed host use nmtui or nmcli, which drive NetworkManager whichever backend is underneath it. A consumer who wants iwd everywhere sets networking.networkmanager.wifi.backend.

4. What the distribution owns, and what it does not

Owned:

  • Redistributable firmware, on by default. Without it wifi does not come up on a large fraction of real laptops — the author's own two included. A per-model hardware module is not a substitute; several of them do not set it either.

NetworkManager itself is the consumer's line to draw: the template enables it, and it is deliberately not in the distribution's base, because a WSL host manages its own networking.

Not owned:

  • The backend, the SSIDs, and the passphrases. Connections are created at runtime and live in /etc/NetworkManager/system-connections, root-only and outside the flake. A rebuild does not create them and an install does not carry them over — reconnecting is part of setting up a new machine.
  • Anything about the network beyond reaching it. A mesh VPN, a file-sync hub and the credentials for either are consumer decisions; if your flake joins one, the usual place is the first-boot script. See Installation.

A consumer who wants wifi credentials rebuilt rather than retyped can declare them: networking.networkmanager.ensureProfiles takes connection profiles, with secrets (if any) kept in the secret store like every other credential — see Secrets.

5. When it does not come up

  • The radio is off. nmcli radio reports it; nmcli radio wifi on turns it back on. A hardware kill switch or a firmware setting can hold it off.
  • The device is missing entirely. If nmcli device status does not list a wifi device, this is not a NetworkManager problem — the driver or its firmware is not loading. That is a hardware fact about the machine, and it belongs in the consumer's flake.
  • The connection is there but nothing resolves. nmcli general status and nmcli device status separate "associated" from "usable". Association without a route or DNS is usually an upstream problem, not a local one.

6. Ongoing

Once connected, the machine behaves like any other: rebuild with Build and Deploy, and keep it current the same way.