Introduzione

Nel nostro percorso di sviluppo di dispositivi IoT Linux, la gestione delle connessioni WiFi si è rivelata tanto cruciale quanto quella delle connessioni 4G (trattate nel nostro precedente articolo).
Dalla configurazione di semplici client che si connettono a reti esistenti, fino alla creazione di access point per reti mesh o configurazioni iniziali, abbiamo esplorato diverse soluzioni tecniche.

Questo articolo racconta la nostra esperienza pratica con gli strumenti di configurazione WiFi più diffusi: partendo dall’approccio tradizionale con hostapd e dnsmasq per la gestione manuale, fino ad arrivare a NetworkManager per scenari più complessi.
Condivideremo i problemi che abbiamo incontrato, le soluzioni che abbiamo sviluppato e i criteri che utilizziamo oggi per scegliere l’approccio più appropriato per ogni progetto.

Configurazione WiFi Client

L’approccio tradizionale: wpa_supplicant e dhcpcd

Nei nostri primi progetti, la configurazione di un client WiFi sembrava un compito relativamente semplice: modificare alcuni file di configurazione e avviare i servizi necessari.
L’approccio classico utilizzava wpa_supplicant per la gestione dell’autenticazione e dhcpcd per l’assegnazione dell’IP.

I vantaggi che abbiamo apprezzato

Controllo granulare: La configurazione diretta attraverso /etc/wpa_supplicant/wpa_supplicant.conf ci dava pieno controllo su ogni aspetto della connessione:

# /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
}

Leggerezza estrema: Su dispositivi con risorse limitate (64-128MB RAM), questo approccio consumava pochissime risorse, lasciando spazio per l’applicazione principale.

Trasparenza completa: Ogni parametro era esplicito e modificabile. Potevamo facilmente personalizzare timeout, algoritmi di cifratura, e comportamenti specifici per ogni rete.

I problemi che ci hanno fatto riflettere

Gestione delle disconnessioni: Come per wvdial con il 4G, la gestione automatica delle riconnessioni era problematica. Quando la connessione si interrompeva, dovevamo implementare script esterni per rilevare la situazione e riconnettersi.

Configurazione statica: Ogni cambio di rete richiedeva modifiche manuali ai file di configurazione. Non c’era un modo semplice per gestire dinamicamente nuove reti o cambiamenti di password.

Debugging complesso: Quando qualcosa non funzionava, dovevamo analizzare manualmente i log di wpa_supplicant e dhcpcd, spesso senza informazioni chiare sul problema.

Quando scegliere l’approccio tradizionale

Nonostante i limiti, l’approccio con wpa_supplicant rimane la nostra scelta per:

Dispositivi con meno di 256MB di RAM
Progetti con configurazioni WiFi statiche e prevedibili
Situazioni dove abbiamo pieno controllo dell’ambiente
Installazioni dove possiamo tollerare brevi interruzioni di connessione

Configurazione di Access Point

La necessità di creare hotspot WiFi

In molti progetti IoT, i dispositivi devono fungere da access point per permettere la configurazione iniziale tramite smartphone o tablet, o per creare reti mesh locali. La combinazione di hostapd per la gestione dell’access point e dnsmasq per DHCP e DNS si è rivelata la soluzione più affidabile.

Configurazione di hostapd

La configurazione di hostapd richiede precisione, soprattutto per quanto riguarda la compatibilità hardware:

# /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

Configurazione di dnsmasq

Dnsmasq gestisce sia DHCP che DNS per i client connessi:

# /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

Routing del traffico da altra interfaccia

Per semplificare l’attivazione dell’access point, la configurazione di base di hostapd e dnsmasq è sufficiente per creare una rete WiFi funzionante.
Tuttavia, due considerazioni importanti riguardano la gestione del traffico di rete quando il dispositivo deve fungere da gateway per fornire connettività Internet ai client connessi.

Routing del traffico verso interfacce cablate (eth0)

Quando il dispositivo IoT è connesso via Ethernet e deve condividere questa connessione con i client WiFi, è necessario configurare il NAT attraverso iptables.
Questo scenario è comune nei gateway industriali dove la connessione primaria avviene via cavo e il WiFi serve per dispositivi mobili o configurazione:

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

# Configurazione NAT per traffico da WiFi verso 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 del traffico verso interfacce cellulari (wwan0)

Nei deployment dove il dispositivo utilizza una connessione 4G come uplink principale, la configurazione delle iptables deve tenere conto delle interfacce wwan tipiche dei modem cellulari.
Questo scenario richiede particolare attenzione alla gestione delle MTU e dei timeout, dato che le connessioni cellulari possono avere latenze variabili:

# NAT verso interfaccia cellulare
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

# Ottimizzazione MTU per connessioni cellulari
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Queste configurazioni di routing sono fondamentali per trasformare il dispositivo IoT in un vero gateway di rete, permettendo ai client WiFi di accedere a Internet attraverso la connessione primaria del dispositivo.

I vantaggi di hostapd + dnsmasq

Controllo completo: Possiamo configurare ogni aspetto dell’access point, dalla crittografia ai canali utilizzati.
Affidabilità: Una volta configurati correttamente, questi strumenti sono estremamente stabili.
Leggerezza: Il consumo di risorse è minimo, ideale per dispositivi embedded.
Flessibilità: Possiamo facilmente integrare funzionalità personalizzate come portali captive o configurazioni dinamiche.

Le sfide incontrate

Configurazione hardware-specifica: Ogni adattatore WiFi ha le sue peculiarità. Alcuni supportano solo determinati canali, altri hanno limitazioni sui driver.
Gestione del dual-mode: Far funzionare lo stesso adattatore WiFi sia come client che come access point richiede script complessi per il cambio di modalità.
Debugging complesso: Quando l’AP non funziona, le cause possono essere molteplici: driver, firmware, configurazione canali, interferenze.

L’evoluzione verso NetworkManager

Un fattore determinante nella nostra scelta è stato la possibilità di utilizzare lo stesso strumento già selezionato per le connessioni 4G.
Come descritto nel nostro articolo precedente sulla gestione delle connessioni cellulari, NetworkManager si era già dimostrato la soluzione più robusta per la gestione dei modem 4G in ambienti di produzione.

Utilizzare lo stesso framework per entrambe le tecnologie di connettività ci ha permesso di standardizzare gli strumenti di gestione, semplificare la manutenzione e ridurre la complessità operativa dei nostri dispositivi IoT.

NetworkManager prometteva quindi di unificare la gestione di tutte le connessioni di rete – WiFi, Ethernet e cellulari – attraverso un’interfaccia coerente e strumenti di debugging comuni, eliminando la necessità di mantenere competenze e procedure separate per tecnologie diverse.

I vantaggi immediati di NetworkManager

Gestione unificata di client e access point

Con NetworkManager, possiamo gestire sia connessioni client che access point attraverso la stessa interfaccia:

# Connessione come client
nmcli device wifi connect "NetworkName" password "NetworkPassword"

# Creazione di un hotspot
nmcli device wifi hotspot con-name "MyHotspot" ssid "IoTDevice" password "SetupPass123"

# Switch tra modalità
nmcli connection up "NetworkName"  # Modalità client
nmcli connection up "MyHotspot"    # Modalità AP

Configurazioni persistenti e profili

NetworkManager mantiene profili persistenti che semplificano la gestione:

# Creazione di un profilo WiFi con configurazioni avanzate
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

# Configurazione IP statico
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

Gestione automatica delle riconnessioni

NetworkManager gestisce automaticamente:

Riconnessioni dopo interruzioni temporanee
Roaming tra access point della stessa rete
Failover tra reti con priorità diverse
Riconnessione automatica all’avvio

Le sfide con NetworkManager

Maggiore consumo di risorse: NetworkManager richiede più RAM e CPU rispetto all’approccio tradizionale. Su dispositivi con 256MB di RAM, abbiamo notato un impatto significativo, soprattutto durante le scansioni WiFi e le riconnessioni.
Complessità di debugging: quando qualcosa non funziona con NetworkManager, il debugging coinvolge più livelli.
Configurazioni avanzate più complesse: per scenari molto specifici, NetworkManager può risultare più complesso da configurare rispetto agli strumenti tradizionali. Ad esempio, configurazioni di bridging avanzate o integrazione con VPN richiedono una comprensione approfondita dell’architettura di NetworkManager.

Strumenti di diagnostica e monitoring

Il nostro toolkit per il debugging WiFi

Indipendentemente dallo strumento scelto, abbiamo sviluppato procedure standardizzate per diagnosticare problemi WiFi:

Verifica dello stato delle interfacce

# Stato generale delle interfacce
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'

Monitoring del traffico

# Statistiche interfaccia
cat /proc/net/dev | grep wlan0
ifconfig wlan0

# Monitoring in tempo reale
iftop -i wlan0
nethogs wlan0

Debugging avanzato

# Log dettagliati wpa_supplicant
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -d

# Monitoring NetworkManager
journalctl -u NetworkManager -f

# Scansione dettagliata reti
iw wlan0 scan dump

Criteri di scelta basati sulla nostra esperienza

Matrice decisionale

Dopo anni di progetti, abbiamo definito criteri chiari per scegliere l’approccio migliore:

Scegliere wpa_supplicant + dhcpcd quando:

RAM disponibile < 256MB
Configurazioni WiFi statiche e prevedibili
Controllo granulare necessario su parametri specifici
Team con competenze sistemistiche avanzate
Tolleranza per interruzioni brevi del servizio
Budget hardware molto limitato

Scegliere hostapd + dnsmasq quando:

Necessità di creare access point dedicati
Configurazioni AP statiche e specializzate
Integrazione con portali captive personalizzati
Controllo completo sui parametri dell’access point
Dispositivi che fungono principalmente da AP

Scegliere NetworkManager quando:

RAM disponibile > 512MB
Necessità di switch dinamico client/AP
Gestione di multiple reti WiFi
Requisiti di roaming automatico
Configurazioni complesse (VPN, bridging, failover)
Team con competenze di system administration standard
Progetti che richiedono manutenzione semplificata

Conclusioni e raccomandazioni

La nostra esperienza nella gestione WiFi per dispositivi IoT Linux ci ha insegnato che non esiste una soluzione universale. La scelta deve sempre essere guidata dai requisiti specifici del progetto.

Le lezioni apprese

Semplicità vs Funzionalità: L’approccio tradizionale con wpa_supplicant e hostapd offre il massimo controllo e la minima overhead, ma richiede più lavoro di implementazione per scenari complessi.
NetworkManager come acceleratore: Per progetti che richiedono funzionalità avanzate, NetworkManager accelera significativamente lo sviluppo, ma con un costo in termini di risorse.
L’importanza della diagnostica: Indipendentemente dall’approccio scelto, avere strumenti di diagnostica standardizzati è fondamentale per la manutenzione e il debugging.
Configurazioni ibride: In alcuni casi, la combinazione di approcci diversi per scenari diversi risulta la soluzione più efficace.

Strumenti emergenti

Stiamo monitorando l’evoluzione di iwd (Intel’s iNet Wireless Daemon) come alternativa moderna a wpa_supplicant, che promette migliori performance e un’architettura più pulita, soprattutto per dispositivi moderni.

Il futuro della connettività WiFi IoT

Con l’evoluzione verso WiFi 6/6E e la crescente adozione di mesh networks, prevediamo che strumenti come NetworkManager diventeranno sempre più centrali nella gestione della connettività IoT, mentre l’approccio tradizionale rimarrà rilevante per dispositivi con vincoli estremi di risorse.

La gestione della connettività WiFi continua ad essere un aspetto critico dei progetti IoT, e la scelta degli strumenti giusti può fare la differenza tra un deployment di successo e problemi operativi continui.

Hai avuto esperienze simili nella gestione di connessioni WiFi su dispositivi IoT, oppure ti serve supporto per configurare la connettività del tuo progetto? Contattaci per condividere la tua esperienza o per ricevere assistenza tecnica specializzata!

Configurazione di moduli WiFi per dispositivi IoT Linux