Networking on Marcello Barnaba

wifi-dethrash: trovare e risolvere il thrashing WiFi mesh su OpenWrt

Fri, 03 Apr 2026 00:00:00 +0000

Tutto è cominciato con il rilevamento presenza WiFi. Avevo costruito un sistema che traccia in quale stanza si trova ognuno scrapando l’RSSI dai miei AP OpenWrt. Funzionava – ma le assegnazioni delle stanze continuavano a sfarfallare. Cucina. Ufficio. Cucina. Ufficio. Tre volte in dieci secondi. La macchina a stati era a posto. Il WiFi no.

La mia rete domestica ha sei AP OpenWrt su tre piani, due SSID – Mercury su 5 GHz, Saturn su 2,4 GHz – tutti con 802.11r per il roaming veloce. Vista da fuori, sembra una mesh fatta bene. Vista da dentro, un telefono rimbalzava tra access point 129 volte in 24 ore.

Non lo sapevo finché non ho costruito lo strumento per vederlo.

Ogni riga è un client WiFi, il colore mostra a quale AP è connesso. I client sani mostrano barre lunghe e piene. Quelli malati sembrano pali da barbiere. Vedi sara-iphone? Quella striscia arcobaleno sono 129 connessioni in 24 ore – il telefono cammina in una zona di overlap tra due AP dove entrambi hanno un segnale circa uguale (e orrendo).

Il problema che non puoi vedere

Il roaming WiFi è invisibile. Il tuo telefono mostra tutte le tacche, Netflix bufferizza un attimo, e tu dai la colpa alla connessione internet. Ma quello che è successo davvero è che il tuo telefono si è disconnesso da un AP, ha scansionato le alternative, ne ha scelto un altro con un segnale marginalmente diverso, si è associato, autenticato, e ha ricominciato lo streaming – tutto in meno di un secondo se 802.11r funziona, diversi secondi se non funziona.

Rilevamento presenza WiFi per Home Assistant con OpenWrt

Sun, 15 Feb 2026 00:00:00 +0000

Avevo due problemi con il rilevamento presenza di Home Assistant.

Il primo: il GPS ti dice se qualcuno è a casa, ma non dove in casa si trova. La mia casa ha sei access point OpenWrt distribuiti su tre piani. Sanno già esattamente quale telefono è connesso a quale AP in ogni momento – sono dati di presenza a livello di stanza, lì nello stack WiFi, che urlano per essere usati. Sapere chi è in quale stanza apre un’intera classe di automazioni che il GPS non può toccare: luci che ti seguono, climatizzazione per stanza occupata, una dashboard che mostra la situazione della casa a colpo d’occhio.

Il secondo: la nostra donna delle pulizie sta a casa nostra un paio di giorni a settimana. Non voglio configurarle un account HA completo, installarle l’app companion sul telefono, o avere a che fare con i permessi GPS. Ma devo sapere se è a casa – perché la mia automazione dell’allarme ha bisogno di sapere se la casa è davvero vuota prima di attivarsi. Il suo telefono si connette al WiFi. Mi basta questo.

Così ho scritto openwrt-ha-presence: una macchina a stati che scrapa le metriche RSSI direttamente dai tuoi AP OpenWrt, capisce in quale stanza si trova ogni persona in base alla potenza del segnale, e pubblica lo stato casa/fuori per ogni persona su Home Assistant via MQTT Discovery. Niente cloud, niente beacon, niente parsing di log, niente database time-series. Python, async, ~600 righe di logica effettiva.

5G come backup della fibra: non perdere mai più una riunione

Sat, 31 Jan 2026 00:00:00 +0000

Un paio di mesi fa, la fibra è andata giù. Come da primo corollario di Murphy, è successo nel momento peggiore in assoluto: subito prima di una riunione cruciale con un’azienda partner. Mi sono ritrovato a saltare freneticamente tra l’AP di un vicino lontano e l’hotspot del telefono, ma entrambi facevano schifo. Parliamo di 200ms di RTT e 15% di packet loss. Mi stavo scusando a profusione mentre il mio feed video si trasformava in uno slideshow del 1998; nessuno capiva una parola di quello che dicevo. Ho finito per spegnere il video e stare zitto. Opportunità persa. Mai. Più.

Così sono andato in modalità paranoica totale e ho costruito un setup di backup 5G serio.

L’hardware

GL.iNet X-3000 con modem Quectel RM520N-GL
Poynting XPOL-24 antenna direzionale montata sul muro fuori dal mio ufficio

Il segnale 5G qui è inesistente, quindi ho dovuto usare l’artiglieria pesante. La Poynting è una bestia. 11 dBi di guadagno, vero MIMO 4x4, cross-polarizzata, stagna. Puntala verso la torre più vicina e all’improvviso il SINR salta da “meh” a “porco dio!”.

Ma puntare un’antenna direzionale senza feedback visivo è doloroso. In pratica giri in tondo, aggiorni una web UI, bestemmi guardando il cielo.

Il software

Ho scritto un set di strumenti per risolvere il problema: quectel-5g-tools.

5g-info scarica tutto quello che il tuo modem sa in un formato leggibile:

5g-monitor è una TUI ncurses che si aggiorna in tempo reale e – qui viene il bello – emette beep in base al SINR. Qualità del segnale più alta = più beep. Punta l’antenna, ascolta i beep, stringi i bulloni. Fatto.

Docker vs. iptables: una storia di rabbia e la chain DOCKER-USER

Fri, 30 Jan 2026 00:00:00 +0100

Siamo nel 2026, e stiamo ancora lottando con l’arroganza assoluta di Docker riguardo al networking Linux.

Ecco lo scenario: faccio girare un host ibrido. Da un lato, ho una macchina virtuale KVM che fa girare Home Assistant (perché ho bisogno del controllo completo del SO e della cifratura del disco). Dall’altro, ho la solita lista di container Docker – NUT per monitorare il mio UPS Lakeview (Vultech) di merda e Technitium per DNS e DHCP – in esecuzione direttamente sull’host.

Sembra semplice. Dovrebbe essere semplice.

Ma nel momento in cui ho installato Docker, la comunicazione con la mia VM Home Assistant è morta. Semplicemente cessata di esistere.

Il problema: Docker è un dittatore

Docker, per default, tratta le tue regole iptables come se fossero semplici suggerimenti. Quando il demone si avvia, sostanzialmente sovrascrive la chain FORWARD, inserisce la sua logica, e imposta policy che isolano efficacemente qualsiasi cosa non sia un container gestito da Docker stesso.

Se hai un’interfaccia bridge per una VM (come br0 o virbr0), le regole di Docker spesso finiscono per droppare i pacchetti destinati a quella VM perché non corrispondono alla sua logica interna per il traffico dei container.

La soluzione ingenua (e perché fallisce)

La mia prima reazione – come qualsiasi sysadmin che fa questo lavoro dai primi anni 2000 – è stata sistemare le regole a mano e poi eseguire:

iptables-save > /etc/iptables/rules.v4

Questa è una trappola!

Se usi iptables-persistent (o netfilter-persistent) con Docker, stai entrando in un mondo di dolore per due motivi:

Workshop Girl Geek Dinners @Apple Store, 16 maggio 2009, Roma

Mon, 18 May 2009 15:00:00 +0000

«Donne! E' arrivato l'arrotino!» – A parte gli scherzi ;) l'Apple Store italiano insieme a Girl Geek Dinners Roma ha organizzato il 16 maggio 2009 un workshop sul mobile lifestyle (incentrato sull'iPhone, ovviamente).

Partiamo dall'inizio: cosa sono le Girl Geek Dinners? Linda ha spiegato al pubblico (circa 20 persone) che un geek e' una persona appassionata di tecnologia in senso ampio: il GGD e' un gruppo dedicato ad aggregare donne interessate a internet, ai nuovi media e agli stili di vita tecnologici. Le donne sono spesso sottovalutate nelle comunita' geek, e questo imbarazzante cliche' ha generato molte discussioni in passato, e la questione e' ancora irrisolta (secondo me).

Il gruppo italiano GGD e' nato nel 2007 a Milano, poi e' arrivato a Roma nel 2008, ed e' presente anche a Bologna e nelle Marche e in Emilia-Romagna.

Quindi, il gruppo GGD cerca di generare una “massa critica” di donne geek, per abolire lo stereotipo che “programmatori / utenti esperti” siano solo uomini: negli eventi GGD i ragazzi ascoltano e le ragazze parlano, poi bloggano, si scambiano biglietti da visita (e chiavi PGP, immagino ;) e in generale cercano di valorizzare il potere e le competenze delle donne nel campo dell'industria informatica. Il networking e un tuffo nei social media sono il modo piu' efficiente al giorno d'oggi per raggiungere un grande pubblico e costruire rapidamente la suddetta massa critica: ecco perche' l'evento GGD era incentrato sulle applicazioni mobile social e di produttivita' in generale. Presentato da due Apple Trainer ufficiali (Simona e Riccardo), il workshop e' iniziato alle 11:30 e e' durato circa un'ora.

Facebook Developer Garage 2009, Milano (Italia)

Sun, 26 Apr 2009 23:00:00 +0000

Questo e' il mio resoconto del primo facebook developer garage italiano, tenutosi a Milano il 23 aprile 2009, e ospitato da mikamai. La mattina e' stata dedicata alle sessioni per sviluppatori, il pomeriggio a quelle di marketing & comunicazione. Alcuni video dell'evento sono disponibili qui.

Mattina: sessione sviluppatori

Il primo talk e' stato tenuto da James Leszczenski, ingegnere di Facebook, che ha presentato la visione, la missione e i valori della piattaforma connect. Interessante, oltre al talk in se', per la partecipazione del pubblico: la platea era profondamente interessata a sapere quali informazioni si ottengono da Facebook, come gestirle, e quali strumenti connect fornisce per collegare identita' e trovare amici su un sito web abilitato.

Piu' tardi ho avuto occasione di chiedere a James se FB fosse incline o meno ad adottare OpenID come metodo di autenticazione: ha detto che connect e OpenID permettono entrambi agli utenti di avere credenziali di login uniche per accedere a piu' siti, ma connect permette anche di sfruttare la potenza del social graph di Facebook per consentire agli utenti di comunicare e condividere informazioni. Quindi, la risposta breve e' “no”. Allora gli ho proposto di implementare OpenID su FB stesso, cosi' che connect potesse diventare davvero un superset di OpenID, ma ha risposto che “come azienda, queste sono decisioni difficili e non posso dare una risposta adesso”. Comprensibile :).

AGGIORNAMENTO: il 27 aprile 2009, TechCrunch riporta di aver sentito che Facebook abbraccera' OpenID come mezzo per autenticare gli utenti. Ottime notizie, in attesa di una dichiarazione ufficiale da Facebook! :)

Il secondo talk e' stato tenuto da Vincenzo Acinapura, che ha descritto gli strumenti di base per creare un'applicazione sulla piattaforma Facebook. Ha esplorato le tecnologie che ci stanno dietro (XFBML, FQL, FBJS), i principali punti di integrazione all'interno della piattaforma (notifiche, publisher, ...) e ha mostrato codice d'esempio per implementare alcuni dei tag FBML piu' usati (fb:comments, fb:share, fb:feed, e cosi' via). Infine ha ricordato l'importanza di automatizzare il deploy delle applicazioni, e ha suggerito di usare capistrano per farlo.

La fine dell'anonimato online

Mon, 01 Dec 2008 22:00:00 +0000

Esattamente le parole che mi girano per la testa in questi giorni:

http://www.readwriteweb.com/archives/the_end_of_online_anonymity.php

Quando raggiungeremo il punto in cui l’anonimato online sarà finito, invece di poter essere chi siamo davvero, il fatto di essere diventati così consapevoli di essere sempre registrati, fotografati, tracciati e seguiti, avrà in realtà creato una personalità leggermente alterata. Come i concorrenti dei reality TV, l’atto di essere osservati cambierà il nostro comportamento. L’immagine del nostro brand personale diventerà la nostra identità pubblica e quindi la nostra identità.

Direi che queste parole descrivono perfettamente l’“effetto Facebook”.

Voi che ne pensate?