Introduction

In our journey of developing Linux-based IoT devices, managing WiFi connections has proven to be just as crucial as managing 4G connections (covered in our previous article).
From configuring simple clients that connect to existing networks to creating access points for mesh networks or initial setup, we explored various technical solutions.

This article shares our hands-on experience with the most common WiFi configuration tools: starting from the traditional approach with hostapd and dnsmasq for manual management, up to NetworkManager for more complex scenarios.
We will share the challenges we encountered, the solutions we developed, and the criteria we use today to choose the most appropriate approach for each project.

WiFi Client Configuration

The traditional approach: wpa_supplicant and dhcpcd

In our early projects, configuring a WiFi client seemed like a relatively simple task: modify a few configuration files and start the necessary services.
The classic approach used wpa_supplicant for authentication management and dhcpcd for IP assignment.

The advantages we appreciated

Granular control: Direct configuration through /etc/wpa_supplicant/wpa_supplicant.conf gave us full control over every aspect of the connection:

# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=IT
network={
    ssid="MyNetwork"
    psk="MyPassword"
    key_mgmt=WPA-PSK
    priority=1
}

network={
    ssid="BackupNetwork"  
    psk="BackupPassword"
    key_mgmt=WPA-PSK
    priority=2
}

Extremely lightweight: On devices with limited resources (64–128MB RAM), this approach consumed very little, leaving room for the main application.

Full transparency: Every parameter was explicit and editable. We could easily customize timeouts, encryption algorithms, and network-specific behaviors.

The issues that made us reconsider

Disconnection handling: As with wvdial for 4G, automatic reconnection handling was problematic. When the connection dropped, we had to implement external scripts to detect the condition and reconnect.

Static configuration: Every network change required manual edits to configuration files. There was no simple way to dynamically handle new networks or password changes.

Complex debugging: When something didn’t work, we had to manually analyze wpa_supplicant and dhcpcd logs, often without clear insights into the issue.

When to choose the traditional approach

Despite its limitations, the wpa_supplicant approach remains our choice for:

Devices with less than 256MB RAM
Projects with static, predictable WiFi configurations
Situations where we have full control over the environment
Installations where short connection interruptions are acceptable

Access Point Configuration

The need to create WiFi hotspots

In many IoT projects, devices must act as access points to allow initial setup via smartphone or tablet, or to create local mesh networks. The combination of hostapd for managing the access point and dnsmasq for DHCP and DNS proved to be the most reliable solution.

hostapd configuration

Setting up hostapd requires precision, especially regarding hardware compatibility:

# /etc/hostapd/hostapd.conf
interface=wlan0
driver=nl80211
ssid=IoTDevice-Setup
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=SetupPassword123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

dnsmasq Configuration

Dnsmasq handles both DHCP and DNS for connected clients:

# /etc/dnsmasq.conf
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h
domain=local
address=/setup.local/192.168.4.1

Traffic Routing from Another Interface

To simplify access point activation, the basic configuration of hostapd and dnsmasq is sufficient to create a functional WiFi network.
However, two important considerations arise when managing network traffic if the device needs to act as a gateway to provide Internet connectivity to connected clients.

Routing Traffic to Wired Interfaces (eth0)

When the IoT device is connected via Ethernet and needs to share this connection with WiFi clients, NAT must be configured using iptables.
This scenario is common in industrial gateways where the primary connection is via cable, and WiFi is used for mobile devices or configuration:

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT configuration from WiFi to Ethernet
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

Routing Traffic to Cellular Interfaces (wwan0)

In deployments where the device uses a 4G connection as the main uplink, iptables configuration must consider wwan interfaces typical of cellular modems.
This scenario requires special attention to MTU and timeout handling, as cellular connections can have variable latency:

# NAT to cellular interface
iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE
iptables -A FORWARD -i wwan0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o wwan0 -j ACCEPT

# MTU optimization for cellular connections
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

These routing configurations are essential to turn the IoT device into a true network gateway, allowing WiFi clients to access the Internet through the device’s primary connection.

The Advantages of hostapd + dnsmasq

Full control: We can configure every aspect of the access point, from encryption to the channels used.
Reliability: Once correctly configured, these tools are extremely stable.
Lightweight: Resource consumption is minimal—ideal for embedded devices.
Flexibility: We can easily integrate custom features like captive portals or dynamic configurations.

The Challenges We Faced

Hardware-specific configuration: Each WiFi adapter has its own quirks. Some support only specific channels, others have driver limitations.
Dual-mode management: Running the same WiFi adapter as both client and access point requires complex scripts for mode switching.
Complex debugging: When the AP doesn’t work, the causes can be many: driver issues, firmware, channel configuration, interference.

The Evolution Towards NetworkManager

A key factor in our decision was the ability to use the same tool we had already selected for 4G connections.
As described in our previous article on cellular connection management, NetworkManager had already proven to be the most robust solution for managing 4G modems in production environments.

Using the same framework for both connectivity technologies allowed us to standardize management tools, simplify maintenance, and reduce the operational complexity of our IoT devices.

NetworkManager thus promised to unify the management of all network connections — WiFi, Ethernet, and cellular — through a consistent interface and shared debugging tools, eliminating the need to maintain separate skills and procedures for different technologies.

Immediate Benefits of NetworkManager

Unified Client and Access Point Management

With NetworkManager, we can manage both client and access point connections through the same interface:

# Connect as a client
nmcli device wifi connect "NetworkName" password "NetworkPassword"

# Create a hotspot
nmcli device wifi hotspot con-name "MyHotspot" ssid "IoTDevice" password "SetupPass123"

# Switch between modes
nmcli connection up "NetworkName"  # Client mode
nmcli connection up "MyHotspot"    # Access Point mode

Persistent Configurations and Profiles

NetworkManager maintains persistent profiles that simplify management:

# Create a WiFi profile with advanced settings
nmcli connection add type wifi \
    con-name "ProductionNetwork" \
    ssid "ProdNet" \
    wifi-sec.key-mgmt wpa-psk \
    wifi-sec.psk "SecurePassword" \
    connection.autoconnect yes \
    connection.autoconnect-priority 10

# Static IP configuration
nmcli connection modify "ProductionNetwork" \
    ipv4.method manual \
    ipv4.addresses 192.168.1.100/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns 8.8.8.8,8.8.4.4

Automatic Reconnection Management

NetworkManager automatically handles:

Reconnections after temporary interruptions
Roaming between access points on the same network
Failover between networks with different priorities
Automatic reconnection on startup

Challenges with NetworkManager

Higher resource consumption: NetworkManager requires more RAM and CPU compared to the traditional approach. On devices with 256MB RAM, we observed a significant impact, especially during WiFi scans and reconnections.
More complex debugging: When something doesn’t work with NetworkManager, debugging involves more layers.
More complex advanced configurations: For highly specific scenarios, NetworkManager can be more complex to configure than traditional tools. For example, advanced bridging configurations or VPN integration require a deep understanding of NetworkManager’s architecture.

Diagnostic and Monitoring Tools

Our WiFi Debugging Toolkit

Regardless of the tool used, we have developed standardized procedures for diagnosing WiFi issues:

Interface Status Check

# General interface status
ip addr show
iwconfig
iw dev

# Informazioni specifiche WiFi
iw wlan0 info
iw wlan0 link
iw wlan0 scan | grep -E "(BSS|SSID|signal)"

Test di connettività

# Test di base
ping -c 3 8.8.8.8
ping -c 3 google.com

# Test di performance
iperf3 -c speedtest.net -t 30

# Analisi della qualità del segnale
watch -n 1 'iw wlan0 link'

Traffic Monitoring

# Interface statistics
cat /proc/net/dev | grep wlan0
ifconfig wlan0

# Real-time monitoring
iftop -i wlan0
nethogs wlan0

Advanced Debugging

# Detailed wpa_supplicant logs
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -d

# NetworkManager monitoring
journalctl -u NetworkManager -f

# Detailed network scan
iw wlan0 scan dump

Choice Criteria Based on Our Experience

Decision Matrix

After years of projects, we have defined clear criteria to choose the best approach:

Choose wpa_supplicant + dhcpcd when:

Available RAM < 256MB
Static and predictable WiFi configurations
Granular control needed on specific parameters
Team with advanced system administration skills
Tolerance for brief service interruptions
Very limited hardware budget

Choose hostapd + dnsmasq when:

Need to create dedicated access points
Static and specialized AP configurations
Integration with custom captive portals
Complete control over access point parameters
Devices mainly acting as AP

Choose NetworkManager when:

Available RAM > 512MB
Need for dynamic client/AP switching
Management of multiple WiFi networks
Automatic roaming requirements
Complex configurations (VPN, bridging, failover)
Team with standard system administration skills
Projects requiring simplified maintenance

Conclusions and Recommendations

Our experience in managing WiFi for Linux IoT devices has taught us that there is no one-size-fits-all solution. The choice must always be guided by the specific project requirements.

Lessons Learned

Simplicity vs Functionality: The traditional approach with wpa_supplicant and hostapd offers maximum control and minimal overhead, but requires more implementation work for complex scenarios.
NetworkManager as an accelerator: For projects requiring advanced features, NetworkManager significantly speeds up development, but at a resource cost.
The importance of diagnostics: Regardless of the chosen approach, having standardized diagnostic tools is crucial for maintenance and debugging.
Hybrid configurations: In some cases, combining different approaches for different scenarios turns out to be the most effective solution.

Emerging Tools

We are monitoring the evolution of iwd (Intel’s iNet Wireless Daemon) as a modern alternative to wpa_supplicant, promising better performance and a cleaner architecture, especially for modern devices.

The Future of IoT WiFi Connectivity

With the evolution towards WiFi 6/6E and the growing adoption of mesh networks, we expect tools like NetworkManager to become increasingly central in managing IoT connectivity, while the traditional approach will remain relevant for devices with extreme resource constraints.

Managing WiFi connectivity remains a critical aspect of IoT projects, and choosing the right tools can make the difference between a successful deployment and ongoing operational issues.

Have you had similar experiences managing WiFi connections on IoT devices, or do you need support configuring connectivity for your project? Contact us to share your experience or receive specialized technical assistance!

WiFi Module Configuration for Linux IoT Devices