Impala: a Rust TUI for managing Wi-Fi on Linux through iwd

What Impala solves, and for whom

iwd is a small wireless daemon, and its own tooling is not built for browsing. Impala puts a ratatui interface in front of it so that scanning, connecting, forgetting, toggling autoconnect and sharing credentials happen from a keyboard rather than from a sequence of iwctl commands. The README lists WPA Enterprise (802.1X) support, station and access point modes, QR code network sharing and hidden networks as the features it covers.

The audience is narrow and specific. You need a Linux based OS with iwd already running. That rules out anyone whose wireless stack is NetworkManager, which is the default on most desktop distributions. The README carries an explicit warning: to avoid conflicts, wireless management services like NetworkManager or wpa_supplicant should be disabled. Impala does not abstract that decision away. It assumes you have already committed to iwd as the only thing touching the radio.

That makes it a good fit for a laptop running a minimal distribution, a single-board computer or a headless machine where you want to see what is around without an X session. It is a poor fit for a machine you administer remotely and expect to configure declaratively, because the interface is a full-screen terminal application, not a configuration file you can push.

How Impala talks to iwd

The dependency list in Cargo.toml is the clearest statement of the architecture. Impala depends on iwdrs, pinned as "<= 0.2.6", which is the Rust binding to iwd's D-Bus API. There is no separate network stack inside the project and no shelling out to iwctl. State flows from iwd over D-Bus into the application, and the UI is drawn with ratatui on top of crossterm for terminal input and events.

Concurrency is handled with tokio and async-channel. The event loop receives terminal events and D-Bus updates, then redraws. The presence of futures and async-channel suggests the D-Bus signals from iwd arrive asynchronously and are forwarded to the UI rather than polled in a tight loop, though the README does not document the internals. Configuration is deserialized with serde and toml, logging uses log with env_logger, and the command line is parsed with clap. QR generation uses qrcode and tui-qrcode, which is what backs the sharing feature.

The version pin on iwdrs is worth noticing. It is an upper bound rather than a caret range, so a future iwdrs release will not be picked up automatically. For a project whose entire function is mediating between a daemon and a UI, that is a deliberate choice to avoid upstream API churn, and it also means the binding is the component most likely to need attention when iwd itself changes.

Installing Impala and connecting to a network

There are four documented install paths. Pre-built binaries are on the release page. On Arch Linux the package is in the official repositories, so pacman handles it. Nix users can install from nixpkgs. Everyone else can use crates.io or build from source.

The crates.io route is a single command:

cargo install impala

On Arch, the equivalent is:

pacman -S impala

Nixpkgs users install it with:

nix-env -iA nixpkgs.impala

If you prefer to build it yourself, the README gives this sequence:

git clone https://github.com/pythops/impala
cd impala
cargo build --release

The build produces an executable at target/release/impala, which the README says you can copy to a directory in your $PATH. The release profile in Cargo.toml strips symbols, enables fat LTO and sets codegen-units to 1, so the release build is optimized for size and runtime at the cost of compile time.

Once installed, running the program with no arguments opens the interface:

impala

The README shows that impala also accepts options: -m or --mode with possible values station or ap, and --ascii for an ASCII display when you do not have a Nerd Font installed. Icons are optional, and the ascii setting in the config file does the same thing persistently.

From inside the interface, the defaults shown in the README are a lowercase r to switch, i to show device information, o to toggle power, s to toggle scanning in station mode, t to toggle autoconnect on a known network, d to remove one, a to show all, and p to share. In access point mode, n starts the access point and x stops it. These are the values in the sample config, not fixed behavior, and the README points at the ratatui Color documentation for valid theme values.

The config file is where the rough edges show

Impala reads $HOME/.config/impala/config.toml for keybindings and theme. The sample in the README is thorough enough to copy, with sections for device, access_point, station, station.known_network and station.new_network, plus a theme block covering background, border, text_color, hidden_color, info_color, warning_color and error_color.

Two entries in that sample deserve a second look. The key for connecting to a hidden network, connect_hidden under station.new_network, is shown as an empty string. An empty keybinding in a sample config is ambiguous: it could mean the feature has no default binding, or that the sample simply left it out. The README does not say which, and it does not list the available actions anywhere else. A reader who wants to connect to a hidden network, one of the four advertised features, has to work out the binding from the sample's silence.

The esc_quit option is clearer but still a choice you have to make. It defaults to false, so Esc does not quit the application. The comment says setting it to true enables Esc to quit. For anyone used to terminal applications where Esc backs out of a screen, the default will feel wrong until they change it, and the reason for the default is not explained.

There is also no documented way to validate the config. If you mistype a color name, the README does not describe what happens. It points to the ratatui Color enum for valid values, which is the right reference, but it leaves error handling to the application at runtime.

Where Impala is the wrong tool

The most important limitation is the one stated as a prerequisite. Impala requires iwd, and the README tells you to disable NetworkManager or wpa_supplicant to avoid conflicts. On a distribution where NetworkManager owns the radio, switching to iwd is not a small change: it affects how every other part of the system brings up networking, including VPN integrations, captive portal helpers and desktop applets. Impala is not a replacement for those. It is a front end for a different daemon, and adopting it means adopting that daemon's model.

The second limitation is scope. The README's feature list is about interactive management. There is no documented CLI for connecting to a specific SSID, listing networks in a parseable format or scripting a connection. The options shown by impala --help are mode selection and ASCII display, nothing more. If you are provisioning machines or writing a deployment script, this is the wrong tool, and iwctl or direct D-Bus calls are the right layer.

The third is platform. It is Linux only, and the interface is a TUI, so it needs an interactive terminal. It is not something you drive from a cron job or a configuration management run. For a headless server you reach over SSH, the TUI works, but it still requires you to be present at a terminal to answer it.

Finally, the pin on iwdrs at "<= 0.2.6" means the project is tied to a specific range of the binding. That is a maintenance consideration rather than a defect, but it is the kind of constraint that shows up when iwd's own API moves.

Impala compared with iwctl and NetworkManager front ends

The natural alternative is iwctl, the interactive client that ships with iwd. Both talk to the same daemon, so the difference is entirely in the interface. iwctl is a command prompt: you type station wlan0 scan, then station wlan0 get-networks, then station wlan0 connect SSID. Impala replaces that with a full-screen view where networks are listed and selected, and where actions like toggling autoconnect or sharing a QR code are bound to single keys. For someone who connects to the same network daily, iwctl is faster. For someone who scans a lot, browses hidden networks or wants to hand a QR code to a phone, Impala's persistent view is the better fit.

The other comparison is with graphical NetworkManager applets such as nm-applet or the network panel in a desktop environment. Those solve a different problem: they manage a stack that handles wired, wireless, VPN and mobile broadband together, and they integrate with the desktop's secret storage. Impala does none of that. It speaks to iwd only, and its configuration lives in a plain TOML file rather than in a keyring. If your requirement is one consistent networking story across a desktop, a NetworkManager applet is the more coherent choice. If your requirement is a small terminal tool on a machine that already runs iwd, Impala is the more direct one.

A third option is running iwd with no front end at all and letting its own configuration files handle known networks. That is the most scriptable approach and the least interactive. Impala sits between that and a graphical applet: more visual than iwctl, narrower than NetworkManager.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-19, which is recent. The release history shows v0.9.0 on 2026-08-27, preceded by v0.8.1 and v0.8.0 within the same month, so the project is being tagged at a steady pace. The version in Cargo.toml is 0.9.0, matching the latest release. None of that is a guarantee about the future, but it does mean the code is not abandoned.

Upgrade cost is low for the binary paths. On Arch, pacman handles it. On Nix, nixpkgs does. On crates.io, cargo install impala pulls the newest published version. The one thing to check before upgrading is the config file: the README shows a specific set of keys under device, access_point, station, station.known_network and station.new_network. A release that adds an action would need a new key, and an existing config would not have it. The README does not document a migration path or a schema version, so keeping a copy of your config.toml before upgrading is the practical precaution.

On licensing, the project is GPL-3.0, stated both in Cargo.toml and in the README's License section. That is a copyleft licence, which matters if you plan to redistribute a modified binary or link the code into another program. The dependencies are separate works with their own licences, and nothing in the README summarizes them. If you are packaging Impala for a distribution or embedding it in a product, read the licence texts of the crates listed in Cargo.toml rather than assuming they match. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Impala if you already run iwd on a Linux laptop or headless box and want a keyboard-driven way to scan, connect, toggle autoconnect, share a network as a QR code or bring up an access point. Do not adopt it if you depend on NetworkManager, if your distribution has no packaged build and you would rather not compile Rust, or if you need a scripting interface for provisioning: the README documents an interactive TUI, not a command language. Before installing, verify three things: that iwd is running, that NetworkManager and wpa_supplicant are disabled so they do not fight over the device, and that $HOME/.config/impala/config.toml does not already exist with keybindings you would overwrite. Then check which key opens the device panel and which one toggles scanning, because both are configurable and the defaults are the only thing the README shows.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pythops/impala on GitHub
4. README
5. Releases