Raspberry Pi NetworkManager: nmcli Setup and Troubleshooting¶
If networking eventually works but boot is slow, use the NetworkManager wait-online diagnosis guide to inspect startup dependencies and profile activation delays.
Raspberry Pi OS Bookworm and Trixie use NetworkManager to manage normal Ethernet and Wi-Fi connections. Use nmcli for repeatable commands, nmtui for an interactive terminal interface, or Control Centre on the desktop. Avoid editing dhcpcd.conf or a global wpa_supplicant.conf by following instructions written for older releases. Check the active manager with nmcli general status; older installations may differ. See the official Raspberry Pi networking documentation.
Quick answer: Raspberry Pi network not working
Run nmcli device status, ip route, and resolvectl status. If the interface is disconnected, activate the correct NetworkManager profile. If an IP address works but a hostname does not, fix DNS. If neither the gateway nor an IP address responds, investigate the Wi-Fi/Ethernet link and route before changing DNS.
Diagnose the failure layer first¶
| Symptom | Check first | Likely layer |
|---|---|---|
| Wi-Fi SSID is missing | nmcli device wifi list and WLAN country |
Radio, regulatory domain, signal, or channel |
| Device says disconnected | nmcli device status and saved profiles |
NetworkManager profile or authentication |
Address starts with 169.254 |
nmcli -f IP4 device show |
DHCP did not provide an address |
Gateway works, 1.1.1.1 fails |
ip route and router uplink |
Default route or upstream internet |
1.1.1.1 works, names fail |
resolvectl status |
DNS configuration |
| SSH stopped after a change | Local console plus profile clone/rollback | Active profile was replaced or disconnected |
Collect the commands in the quick reference before restarting NetworkManager. Restarting the service can terminate SSH and erase useful transient state.
Command quick reference¶
| Task | Command |
|---|---|
| Overall state | nmcli general status |
| Device state | nmcli device status |
| Active profiles | nmcli connection show --active |
| All profiles | nmcli connection show |
| IP addresses | ip -brief address |
| Routes | ip route and ip -6 route |
| DNS | resolvectl status |
| Wi-Fi scan | nmcli device wifi list |
| Interactive configuration | sudo nmtui |
| NetworkManager logs | journalctl -b -u NetworkManager --no-pager |
For first boot and remote-access choices, start with the headless and networking hub.
When a NetworkManager update fails¶
For an error-by-error recovery workflow, use NetworkManager update failure and APT repair. It covers interrupted dpkg operations, dependency-repair previews, disk space, and protecting remote access.
If sudo apt update or an upgrade reports a network-manager error, first distinguish a broken network connection from a package-management failure. Record the exact error before changing connection profiles or removing packages, especially when connected over SSH.
- Name-resolution or connection timeout: Test the gateway, an IP address, and a hostname separately using DNS diagnostics. Fix the connection before retrying APT.
- Repository or release mismatch: Inspect the APT error and configured sources. Do not combine Bookworm and Trixie repositories to make a package install. For a major release change, follow the Trixie migration guide and the official Raspberry Pi OS update guidance.
- Held package, insufficient space, or interrupted installation: Resolve the reported condition before retrying the update. Do not force-remove NetworkManager from a Pi you administer remotely; that could disconnect it.
For routine updates within the same Raspberry Pi OS release, run sudo apt full-upgrade only after sudo apt update succeeds and you have confirmed adequate free space. A major Bookworm-to-Trixie migration is a separate task, not a repair for a failed package update.
Identify interfaces and profiles¶
Run these before changing anything:
NetworkManager connection profiles have names such as Wired connection 1; devices have names such as eth0 or wlan0. Commands that modify a connection usually require the profile name, not the device name.
Show the profile attached to each active device:
Do not assume that every system uses eth0 and wlan0. Predictable interface naming, USB adapters, and Compute Module hardware can produce other names.
Connect to Wi-Fi¶
Enable the radio and scan:
Use --ask so the password is not placed directly in shell history:
Confirm the active profile:
For a hidden network:
Set the correct Wi-Fi country during Imager setup or through the supported Raspberry Pi configuration interface. The regulatory domain affects legal channels and radio behaviour.
Manage saved Wi-Fi profiles¶
List profiles:
Prefer one network over another with autoconnect priority:
Remove an obsolete profile only after confirming its exact name:
View a profile without printing stored secrets:
Ethernet with DHCP¶
Most networks supply an address, route, and DNS through DHCP. To return a profile to automatic IPv4:
Apply it only when you have local or alternate access:
Cycling the profile disconnects an SSH session using it.
Static IPv4 with NetworkManager¶
When you control the router, prefer a DHCP reservation. Use a device-side static address when the deployment requires it and the address has been reserved in the network plan.
Example values:
Apply them to the actual profile name:
Inspect before activation:
Verify that the address is not already in use and is not available to another DHCP client. Address-conflict checks are network-specific; coordinate with the administrator rather than relying on one ping result.
Make a remote change safely¶
Changing the active profile over SSH can lock you out. Before activation:
- Keep the current SSH session open.
- Prepare Ethernet, USB Gadget, serial, or local-console recovery.
- Record the original profile values.
- Schedule an automatic rollback.
- Apply one change.
- Test from a second client session.
- Cancel the rollback only after verification.
Create a profile clone for a reversible experiment:
A clone reduces accidental damage to the known-good profile, but activating it can still disconnect you.
IPv6¶
Do not disable IPv6 as a generic troubleshooting step. Inspect it independently:
If a deployment intentionally uses no IPv6, document that policy and test the applications before disabling it on a profile.
DNS diagnostics¶
Check configured resolvers and per-interface domains:
Test layers separately:
If an IP works but a hostname does not, investigate DNS. If the gateway cannot be reached, changing public DNS will not fix the link or route.
Route selection and metrics¶
Show routes:
When Ethernet and Wi-Fi are both active, route metrics determine preference. Set a lower metric on the preferred profile:
Reconnect during a maintenance window, then confirm with ip route get.
Create a Wi-Fi hotspot¶
For a quick routed hotspot:
This command places a credential in shell history. Prefer an interactive or protected provisioning workflow on shared systems. For routing models, client isolation, bridge mode, and recovery, see Raspberry Pi Wi-Fi access point.
USB networking¶
Current Trixie images support an official USB Gadget workflow on compatible boards. It presents the Pi as a USB Ethernet device and is useful when no LAN is available.
See SSH over USB with rpi-usb-gadget. Do not confuse USB Ethernet with USB mass-storage emulation.
Hostname and local discovery¶
On networks with mDNS support:
Managed networks can block multicast discovery. Use DHCP/DNS inventory rather than assuming .local works everywhere.
Check link speed and errors¶
Ethernet:
Wi-Fi:
Packet loss, retries, duplex negotiation, low signal, interference, cable quality, and power can all affect throughput. Measure before changing MTU, offload, or radio settings.
Firewall inspection¶
Raspberry Pi OS networking and firewall policy are separate layers. Inspect the active ruleset:
To identify which process initiates short-lived outgoing TCP connections, use the tcpconnect-bpfcc guide for Raspberry Pi. Unlike a socket snapshot, it traces new connection activity while it is running.
If using UFW:
Allow administration from a trusted network before enabling a deny-by-default policy. Keep the current SSH session open while testing a new session.
Diagnostic bundle¶
The following command collection avoids printing Wi-Fi passwords:
Review logs for secrets, public addresses, hostnames, and organisation details before sharing them.
Troubleshooting table¶
| Symptom | First checks | Likely layer |
|---|---|---|
Interface DOWN |
Cable, radio, rfkill, ip -brief link |
Physical/link |
| No IP address | Active profile, DHCP logs, address plan | Network configuration |
| Gateway unreachable | Prefix, route, VLAN, Wi-Fi association | Local network |
| IP works, names fail | resolvectl status, DNS query |
DNS |
| SSH refused | systemctl status ssh, listening sockets |
Service |
| SSH times out | Route, firewall, wrong address | Path/firewall |
| Intermittent disconnects | Power, signal, cable, kernel log | Physical/power |
| Wrong interface used | ip route get, route metrics |
Routing policy |
FAQ¶
Does Raspberry Pi OS Trixie use NetworkManager?¶
Yes for normal desktop, Ethernet, and Wi-Fi profile management. Use nmcli, nmtui, or Control Centre rather than old dhcpcd.conf instructions.
Is a static IP required for a server?¶
No. A DHCP reservation often provides stability with less risk of conflicts. A device-side static profile is useful when the network plan requires it.
Why does editing /etc/resolv.conf not persist?¶
It is normally managed by the active networking and resolver stack. Configure DNS on the NetworkManager profile instead of overwriting generated state.
Should I turn off Wi-Fi when Ethernet connects?¶
Not necessarily. Route metrics can prefer Ethernet while retaining Wi-Fi as a fallback. Test failure behaviour before relying on automatic failover.
How can I avoid losing SSH during a change?¶
Use an alternate connection such as USB Gadget, clone the profile, schedule rollback, keep the old session open, and verify from a second terminal.