Networkmanager vs Wpa Supplicant

NetworkManager and wpa_supplicant solve different layers of the Linux networking stack, but if you're forcing a head-to-head, one of them is the tool you actually configure and the other is the engine it drives. Here's the decisive read.

What they actually are

Stop pretending these are peers. wpa_supplicant is a narrow, excellent daemon that does exactly one thing: it implements the 802.11 client-side authentication handshake — WPA/WPA2/WPA3, EAP, the four-way key exchange. It associates you to an access point and nothing else. It does not manage your IP address, your DNS, your VPN, or your wired interface. NetworkManager is the policy layer that sits above all of that. It decides which connection to bring up, runs DHCP, wires in DNS, juggles VPNs, handles captive portals, and — critically — drives wpa_supplicant (or iwd) as its WiFi backend. So when people pit them against each other, they're comparing a car against its engine. The engine is essential. But you don't drive an engine; you drive the car wrapped around it.

Day-to-day usability

NetworkManager wins this so hard it's almost unfair. nmcli device wifi connect SSID password hunter2 and you're online — DHCP, DNS, and reconnect-on-wake all handled. nmtui if you want a menu. GNOME and KDE applets if you want clicks. wpa_supplicant by contrast wants you hand-authoring wpa_supplicant.conf, generating PSKs with wpa_passphrase, then separately invoking dhclient or dhcpcd to actually get an address, then manually sorting DNS. Miss a step and you're associated but unroutable, staring at a link that's 'up' and useless. That gap — associated-but-no-internet — is the single most common way wpa_supplicant humiliates newcomers. NetworkManager closes it by treating the supplicant as an implementation detail you never touch. For anyone who isn't deliberately minimizing dependencies, raw wpa_supplicant is friction theater.

Where wpa_supplicant earns its keep

Don't read the verdict as contempt — wpa_supplicant is load-bearing infrastructure, and on the right target it's the correct and only sane choice. Embedded Linux, routers, IoT, anything where every megabyte and every background process counts: you ship wpa_supplicant alone, scripted, deterministic, with no policy daemon second-guessing your interface state. It's also the right pick when you need fine EAP control for enterprise or 802.1X setups and want the config to be the literal source of truth, not a NetworkManager keyfile abstraction over it. It's rock-solid, portable, and ancient in the good way. The catch: you're now the policy layer. You own reconnection logic, IP acquisition, DNS, and failover. That's a feature on a fixed-function appliance and a liability on a laptop. Use it where its minimalism is the point, not where it's just stubbornness.

The modern wrinkle: iwd

Here's the part that quietly reframes the whole fight: NetworkManager doesn't even need wpa_supplicant anymore. Intel's iwd has become the cleaner, lighter, faster-roaming WiFi backend, and NetworkManager speaks to it natively via wifi.backend=iwd. iwd ships its own minimal DHCP and resolves a lot of wpa_supplicant's cruft and slow-association complaints. So 'NetworkManager vs wpa_supplicant' is increasingly a comparison against a backend you might swap out entirely. That further cements the pick: you commit to the manager — the durable, intent-level interface — and let the supplicant underneath be replaceable. Betting your workflow on talking directly to wpa_supplicant means betting on a specific engine at the exact moment the ecosystem is shopping for a better one. Pick the abstraction that survives the backend changing. That abstraction is NetworkManager.

Quick Comparison

Factor	Networkmanager	Wpa Supplicant
Scope	Full connection manager: WiFi, wired, VPN, DHCP, DNS	802.11 supplicant only — auth and association
Ease of use	nmcli / nmtui / GUI applets, one command online	Hand-edited config plus separate DHCP and DNS steps
Footprint / embedded fit	Heavier, assumes a policy daemon and D-Bus	Tiny, scriptable, ideal for IoT and routers
Roaming and reconnect	Handled automatically across suspend, networks, captive portals	You script it yourself or it just sits associated
Backend flexibility	Can drive wpa_supplicant OR iwd, swappable	Is itself one backend, increasingly replaceable

The Verdict

Use Networkmanager if: You want WiFi, wired, VPN, and DNS managed coherently on a desktop, laptop, or server with one daemon and `nmcli` — and you want roaming, captive portals, and reconnection handled for you.

Use Wpa Supplicant if: You're building an embedded or headless device, need a tiny footprint, or want surgical control over the 802.11 supplicant with no policy daemon in the way.

Consider: They are not really rivals: NetworkManager USES wpa_supplicant (or iwd) under the hood. The real choice is whether you want a manager on top or the raw supplicant alone.

Networkmanager vs Wpa Supplicant: FAQ

Is Networkmanager or Wpa Supplicant better?

Networkmanager is the Nice Pick. For 95% of humans and machines that just need WiFi, Ethernet, VPNs, and roaming to work without hand-editing config files, NetworkManager wins. wpa_supplicant is the brilliant specialist it commands — and almost nobody should be talking to it directly.

When should you use Networkmanager?

You want WiFi, wired, VPN, and DNS managed coherently on a desktop, laptop, or server with one daemon and `nmcli` — and you want roaming, captive portals, and reconnection handled for you.

When should you use Wpa Supplicant?

You're building an embedded or headless device, need a tiny footprint, or want surgical control over the 802.11 supplicant with no policy daemon in the way.

What's the main difference between Networkmanager and Wpa Supplicant?

NetworkManager and wpa_supplicant solve different layers of the Linux networking stack, but if you're forcing a head-to-head, one of them is the tool you actually configure and the other is the engine it drives. Here's the decisive read.

How do Networkmanager and Wpa Supplicant compare on scope?

Networkmanager: Full connection manager: WiFi, wired, VPN, DHCP, DNS. Wpa Supplicant: 802.11 supplicant only — auth and association. Networkmanager wins here.

Are there alternatives to consider beyond Networkmanager and Wpa Supplicant?

They are not really rivals: NetworkManager USES wpa_supplicant (or iwd) under the hood. The real choice is whether you want a manager on top or the raw supplicant alone.

The Bottom Line

Networkmanager wins

For 95% of humans and machines that just need WiFi, Ethernet, VPNs, and roaming to work without hand-editing config files, NetworkManager wins. wpa_supplicant is the brilliant specialist it commands — and almost nobody should be talking to it directly.

Related Comparisons