Skip to content

Raspberry Pi Wi-Fi Access Point with NetworkManager

On Raspberry Pi OS Trixie, NetworkManager can create and manage a Wi-Fi hotspot without a separate hand-written hostapd and dnsmasq setup. Start with routed/shared mode: clients receive private addresses from the Pi and use its Ethernet or other upstream connection through routing and NAT.

Choose the network design

Mode Client subnet Internet sharing Best for
Hotspot only Private subnet on Pi No upstream required Local control panels, field setup
Routed/shared hotspot Private subnet on Pi NAT through upstream Travel router, lab, IoT network
Bridged AP Same subnet as wired LAN No NAT at Pi Managed networks that require one broadcast domain

Routed/shared mode is the most portable. Bridging requires compatible Wi-Fi/driver behaviour and coordinated LAN DHCP/security; it is not a universal upgrade over routing.

Requirements

  • Raspberry Pi with AP-capable Wi-Fi, or a compatible USB Wi-Fi adapter
  • Raspberry Pi OS Trixie
  • Correct Wi-Fi country/regulatory configuration
  • Ethernet or another upstream connection if clients need internet
  • Stable power and cooling appropriate to the workload
  • A local or alternate recovery path before changing the active Wi-Fi profile

Check device and AP capability:

nmcli device status
iw list | sed -n '/Supported interface modes:/,/Band /p'

Look for AP under supported interface modes. Do not assume every USB Wi-Fi adapter supports AP mode with its installed driver.

One-command routed hotspot

Identify the Wi-Fi device:

nmcli device status

Create the hotspot, replacing SSID and passphrase:

1
2
3
4
5
sudo nmcli device wifi hotspot \
  ifname wlan0 \
  con-name "Pi Hotspot" \
  ssid "Pi-Lab" \
  password "replace-with-a-unique-passphrase"

The password appears in shell history in this example. On shared or audited systems, create the profile interactively or remove the sensitive history entry according to your operational policy.

Inspect the resulting profile without secrets:

1
2
3
4
nmcli --show-secrets no connection show "Pi Hotspot"
nmcli connection show --active
ip -brief address show wlan0
ip route

NetworkManager's shared IPv4 method normally supplies client addressing, DNS forwarding, IP forwarding, and NAT for the connection.

Start, stop, and remove the hotspot

# Stop
sudo nmcli connection down "Pi Hotspot"

# Start
sudo nmcli connection up "Pi Hotspot"

# Disable automatic start
sudo nmcli connection modify "Pi Hotspot" connection.autoconnect no

# Permanently remove the profile
sudo nmcli connection delete "Pi Hotspot"

If wlan0 was previously a Wi-Fi client, stopping the hotspot does not necessarily reactivate the old client profile. Start it explicitly:

nmcli connection show
sudo nmcli connection up "Home Wi-Fi"

Confirm routed/shared mode

Check the profile:

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns \
  connection show "Pi Hotspot"

The IPv4 method should be shared. Confirm forwarding and the active firewall rules:

sysctl net.ipv4.ip_forward
sudo nft list ruleset

Avoid adding parallel iptables scripts unless you deliberately replace NetworkManager's shared-mode policy. Competing firewall managers make upgrades and troubleshooting harder.

Choose the upstream connection

Show the default route:

ip route
ip route get 1.1.1.1

For a common design, Ethernet is the upstream and Wi-Fi serves clients:

Internet/router ── Ethernet ── Raspberry Pi ── Wi-Fi hotspot clients

A Raspberry Pi with one Wi-Fi radio can sometimes act as a client and AP simultaneously, but channel constraints, driver support, performance, and recovery become more complex. Prefer Ethernet upstream or a second compatible radio for a dependable deployment.

Set SSID, band, and channel

Change the SSID:

sudo nmcli connection modify "Pi Hotspot" 802-11-wireless.ssid "Pi-Lab"

Show device capabilities and nearby channel use:

iw list
nmcli -f SSID,CHAN,FREQ,RATE,SIGNAL device wifi list

Band and channel properties are driver and regulatory-domain dependent. Example 2.4 GHz configuration:

1
2
3
sudo nmcli connection modify "Pi Hotspot" \
  802-11-wireless.band bg \
  802-11-wireless.channel 6

Reconnect during a maintenance window:

sudo nmcli connection down "Pi Hotspot"
sudo nmcli connection up "Pi Hotspot"

Use only channels permitted by the configured country, and select a channel after measuring local use rather than copying a universal value.

Security configuration

Use a long unique passphrase. Inspect the active key-management setting without exposing the secret:

nmcli --show-secrets no -f 802-11-wireless-security \
  connection show "Pi Hotspot"

NetworkManager and client support determine whether WPA2, WPA3/SAE, or transition mode is practical. Test every client class before enforcing a new mode.

Additional controls:

  • Keep administrative SSH and dashboards off the guest interface unless required.
  • Apply firewall rules by interface and service.
  • Use client isolation when supported and required.
  • Do not reuse a personal Wi-Fi password.
  • Rotate credentials when devices leave the deployment.
  • Keep Raspberry Pi OS and firmware packages updated.

List listening services before exposing the hotspot:

sudo ss -lntup
sudo nft list ruleset

Allow only required Pi services

If clients need one local application, bind it deliberately and limit firewall access to the hotspot interface/subnet. Do not expose SSH, databases, and development servers merely because they listen on every address.

Check application bind addresses:

sudo ss -lntp

For UFW-managed systems, inspect before changing:

sudo ufw status verbose

Firewall syntax and interface names must match the actual deployment. Keep local access while testing deny rules.

Hotspot without internet

A local-only hotspot can serve a setup page or controller. Clients may report “no internet” and prefer another network; that is client operating-system behaviour, not necessarily a hotspot failure.

Test local addressing and service access separately from internet routing:

ip -brief address show wlan0
sudo ss -lntup

If clients need reliable name resolution for a local service, plan local DNS and certificates instead of depending only on a guessed hostname.

Bridge mode considerations

Bridge mode places Wi-Fi clients on the wired LAN. Before attempting it, confirm:

  • The Wi-Fi hardware and driver support the required AP/bridge operation.
  • The upstream network permits additional client MAC addresses.
  • DHCP comes from the wired LAN.
  • Port security, VLANs, and spanning-tree policy are coordinated.
  • A management path remains if the bridge fails.

Do not combine a bridge, NetworkManager shared mode, and separate NAT scripts. Choose one design and verify the packet path.

For many home and IoT deployments, routed mode provides clearer isolation and fewer broadcast-domain surprises.

Client and lease visibility

Show associated stations:

iw dev wlan0 station dump

Show neighbour entries learned by the Pi:

ip neigh show dev wlan0

These are observations, not an authoritative user identity system. MAC randomisation and lease changes can alter entries.

Measure performance

Record:

  • Raspberry Pi model and radio/adapter
  • Band, channel, channel width, and country
  • Client model and distance
  • Signal and retry statistics
  • Upstream connection
  • TCP throughput in both directions
  • Latency and packet loss
  • CPU temperature and throttling

Use iperf3 between a client and a wired system you control:

sudo apt install -y iperf3
iperf3 -s

From the client:

iperf3 -c HOTSPOT_SERVER_ADDRESS -t 30
iperf3 -c HOTSPOT_SERVER_ADDRESS -R -t 30

Do not present internet speed-test results as Wi-Fi capacity; the WAN can be the bottleneck.

Troubleshooting order

Hotspot profile will not start

1
2
3
4
5
nmcli device status
nmcli connection show "Pi Hotspot"
journalctl -b -u NetworkManager --no-pager
rfkill list
iw list

Confirm AP support, radio state, country, interface name, and whether another profile owns the device.

Client sees the SSID but cannot join

Check security compatibility, passphrase, regulatory channel, and NetworkManager logs. Temporarily test with a different supported band/channel rather than disabling security.

Client joins but receives no address

1
2
3
4
ip -brief address show wlan0
nmcli -f ipv4.method connection show "Pi Hotspot"
sudo nft list ruleset
journalctl -b -u NetworkManager --no-pager

Confirm ipv4.method shared and avoid a second DHCP service binding the same interface.

Local access works but internet does not

1
2
3
4
ip route
ip route get 1.1.1.1
sysctl net.ipv4.ip_forward
sudo nft list ruleset

Test upstream connectivity on the Pi first, then NAT/routing, then DNS from the client.

Throughput is unstable

Check signal, retries, interference, power, temperature, and concurrent use:

1
2
3
4
iw dev wlan0 station dump
vcgencmd measure_temp
vcgencmd get_throttled
journalctl -b -k --no-pager | grep -Ei 'wlan|brcm|usb|under.?voltage'

Recovery

If the Pi becomes unreachable after changing Wi-Fi:

  1. Connect Ethernet if configured.
  2. Use USB Gadget Mode on a supported board.
  3. Use a local console.
  4. Start the previous NetworkManager profile.
  5. Delete or repair the failed hotspot profile only after regaining access.
nmcli connection show
sudo nmcli connection up "Known Good Connection"

FAQ

Do I still need hostapd and dnsmasq?

Not for the standard Trixie NetworkManager hotspot. Manual services remain useful for specialised designs, but then you own their interaction with NetworkManager, DHCP, DNS, firewall, and upgrades.

Can Raspberry Pi create a 5 GHz hotspot?

It depends on the model, adapter, driver, regulatory country, and supported channels. Confirm with iw list on the actual device.

Can the Pi use Wi-Fi for both upstream and hotspot?

Some hardware/driver combinations support concurrent roles with constraints. For reliability, prefer Ethernet upstream or a second compatible Wi-Fi adapter.

Is bridge mode faster than routed mode?

Not inherently. It changes network topology. Throughput depends on radio, driver, CPU, traffic path, and upstream link. Choose based on addressing and isolation requirements.

How do I hide the SSID?

Hidden SSIDs do not provide meaningful security and can complicate client behaviour. Use strong authentication and network isolation.