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:
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:
Create the hotspot, replacing SSID and 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:
NetworkManager's shared IPv4 method normally supplies client addressing, DNS forwarding, IP forwarding, and NAT for the connection.
Start, stop, and remove the hotspot¶
If wlan0 was previously a Wi-Fi client, stopping the hotspot does not necessarily reactivate the old client profile. Start it explicitly:
Confirm routed/shared mode¶
Check the profile:
The IPv4 method should be shared. Confirm forwarding and the active firewall rules:
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:
For a common design, Ethernet is the upstream and Wi-Fi serves 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:
Show device capabilities and nearby channel use:
Band and channel properties are driver and regulatory-domain dependent. Example 2.4 GHz configuration:
Reconnect during a maintenance window:
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:
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:
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:
For UFW-managed systems, inspect before changing:
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:
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:
Show neighbour entries learned by the Pi:
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:
From the client:
Do not present internet speed-test results as Wi-Fi capacity; the WAN can be the bottleneck.
Troubleshooting order¶
Hotspot profile will not start¶
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¶
Confirm ipv4.method shared and avoid a second DHCP service binding the same interface.
Local access works but internet does not¶
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:
Recovery¶
If the Pi becomes unreachable after changing Wi-Fi:
- Connect Ethernet if configured.
- Use USB Gadget Mode on a supported board.
- Use a local console.
- Start the previous NetworkManager profile.
- Delete or repair the failed hotspot profile only after regaining access.
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.