Archivi categoria: Analytics

Meshtastic è trasparente, ma esiste!

E ti porta con se fin dove arriva

Disclaimer

Questa è un’analisi tecnico-divulgativa indipendente. Le verifiche sul campo, le acquisizioni strumentali e lo snapshot topologico sono fonti distinte, con limiti diversi. Non vengono attribuite proprietà dei relay, responsabilità, affiliazioni o condotte scorrette a persone, gruppi o «organizzazioni». La finalità è comprendere i meccanismi della rete, condividerne le opportunità e favorire un confronto documentato.

1. Dalla topologia alla domanda sul transito

Il precedente dossier ha esaminato uno snapshot pubblico di Map4 del 19 ottobre 2026: 927 nodi censiti, di cui 917 associati a MediumFast, 155 a SOS-Italia e 145 presenti in entrambe le classificazioni. Questi dati descrivono associazioni rilevate nel dataset, non la proprietà degli apparati, la loro configurazione completa o il percorso seguito dai singoli messaggi.

Nel grafo ricostruito, l’esclusione ipotetica di 772 nodi classificati MediumFast-only riduceva le coppie di nodi SOS-Italia raggiungibili da 2.237 a 1.923: una differenza di 314 coppie, pari al 14,04%. È una misura relativa al modello delle adiacenze, non una misurazione della consegna radio o della copertura territoriale. Serve a formulare una domanda, non a proclamare una dipendenza operativa dimostrata.

2. Il caso controllato: spare_01, spare_02 e il canale CUSTOM

Nell’esperimento precedente i due endpoint spare_01 e spare_02 dichiaravano esclusivamente un canale logico CUSTOM, impostato come PRIMARY e protetto da una PSK dedicata. Non dichiaravano MediumFast né come canale primario né come secondario. Eppure erano stati osservati messaggi CUSTOM ricevuti con 2 hop e, in alcuni casi, 4 hop.

Gli endpoint Spare erano stati predisposti per una verifica esclusivamente via radio LoRa: MQTT era intenzionalmente escluso, senza uplink o downlink MQTT sul canale CUSTOM. Le ricezioni osservate a 2 e 4 hop rappresentano perciò diversi livelli di attraversamento della mesh radio, non tragitti instradati tramite Internet. Il numero di hop non equivale però a una distanza geografica: i singoli collegamenti possono coprire distanze molto differenti a seconda di visibilità radio, posizione, antenne e presenza dei relay.

L’osservazione mostra che la comunicazione CUSTOM può risultare multihop anche senza l’adesione dei due endpoint al canale pubblico. Non identifica però i relay attraversati né consente, da sola, di stabilire quali apparati terzi abbiano effettivamente partecipato.

Se due nodi condividono soltanto un canale CUSTOM, come può un loro messaggio percorrere più hop attraverso una mesh più ampia? E come possiamo distinguere un pacchetto che il nostro dispositivo comprende da uno che riesce soltanto a osservare?

3. Come funziona il trasporto trasparente

In una mesh Meshtastic è utile separare due livelli. Il livello radio stabilisce se i dispositivi possono ricevere il segnale: dipende dal preset LoRa, dalla regione, dalla frequenza e dalle condizioni di propagazione. Il canale logico stabilisce invece quali messaggi un nodo può decifrare utilizzando il nome del canale e la relativa chiave. Per questo il preset radio MEDIUM_FAST non deve essere confuso con il canale logico MediumFast.

Un pacchetto ricevuto via radio porta metadati necessari al suo trattamento e un contenuto eventualmente cifrato. Se il dispositivo dispone del canale e della chiave corretti può decodificare il messaggio e riconoscerne il tipo. Altrimenti il contenuto resta encrypted / not decoded: il segnale è arrivato, ma il messaggio non è leggibile. La mancata decodifica non equivale automaticamente a mancata ricezione.

Il passaggio ulteriore, cioè la ritrasmissione RF, è un’altra decisione: dipende da ruolo del nodo, modalità di rebroadcast, configurazione del firmware, duplicati e condizioni operative. Dove tale comportamento è consentito, il pacchetto può proseguire senza che il relay ne comprenda il contenuto. La cifratura tutela il messaggio; non definisce da sola, in tutti i casi, l’inoltro. Viceversa, il fatto che un osservatore registri un pacchetto sconosciuto non dimostra che lo abbia a sua volta ritrasmesso.

La documentazione ufficiale Meshtastic conferma questa distinzione: la modalità di rebroadcast ALL può ritrasmettere pacchetti di altre mesh con impostazioni modem compatibili anche quando la cifratura differisce; LOCAL_ONLY limita invece il rebroadcast ai canali locali dichiarati. MQTT è un percorso complementare basato su gateway e collegamento Internet, distinto dai singoli hop radio LoRa. La presenza di questi meccanismi nel protocollo non prova automaticamente quali relay siano stati attraversati in uno specifico scambio.

È questo il significato pratico di trasporto trasparente: un’infrastruttura fisica condivisa può contribuire alla circolazione di traffico destinato a gruppi logici diversi, se i singoli nodi sono configurati per farlo. I nomi dei canali non delimitano necessariamente reti radio fisicamente isolate. Rimangono però indispensabili prove specifiche per ricostruire ogni percorso effettivo.

Come verificare, con un dispositivo di misura, quali pacchetti arrivano, quali sono decodificabili e quali restano soltanto visibili in forma cifrata?

4. Preparazione della prima acquisizione: solo CUSTOM

Per verificare il comportamento osservato nell’esperimento con gli endpoint Spare, è stato utilizzato un dispositivo Heltec V3 con firmware versione 2.7.26 configurato per il troubleshooting della rete, collegato via USB a un client Python. L’acquisizione è distinta dal precedente test multihop di spare_01 e spare_02: non si attribuiscono ai due endpoint pacchetti o misurazioni di questa nuova prova.

Condizione di isolamento del test. Le acquisizioni sono state eseguite attraverso la sola interfaccia radio LoRa, con MQTT volutamente non utilizzato. Sul dispositivo strumentale il log documenta ignore_mqtt: true; nella configurazione dei canali non risultano abilitati i flag di collegamento MQTT uplink_enabled e downlink_enabled, e il modulo MQTT non risulta attivo. I filtri impediscono inoltre di considerare il traffico proveniente da MQTT come prova di transito RF. Il collegamento USB con Python serve soltanto all’acquisizione diagnostica, non al trasporto dei messaggi fra nodi.

Canale logico: un solo PRIMARY CUSTOM con PSK dedicata; nessun SECONDARY dichiarato.
Impostazioni fisiche: preset LoRa MEDIUM_FAST, regione EU868, scheda Heltec V3.
Condizioni di acquisizione: acquisizione USB dopo riavvio del dispositivo, ruolo CLIENT_HIDDEN; conteggi dei messaggi radio distinti dai pacchetti consegnati al client.
Obiettivo: individuare pacchetti sul proprio canale e pacchetti cifrati con hash differenti, senza aggiungere chiavi o canali pubblici.
Esclusione MQTT: nessun bridge Internet utilizzato nelle prove; canali logici senza uplink/downlink MQTT abilitati, ricezioni attribuite a TRANSPORT_LORA.

5. Prima acquisizione — solo CUSTOM: ciò che si riceve e ciò che si comprende

Dopo il riavvio, con il solo canale CUSTOM dichiarato, il dispositivo ha registrato 73 ricezioni LoRa. Di queste, 44 portavano l’hash radio 0x1F, distinto da quello del PRIMARY configurato. Non potendo associare tali pacchetti a una chiave dichiarata, il firmware non ne decodificava il contenuto.

Questo primo campione è stato acquisito senza MQTT: i pacchetti censiti provengono dal ricetrasmettitore LoRa, non da un broker o da un gateway Internet. La presenza di hash di altri canali dimostra la ricezione fisica di quel traffico, mentre non permette, da sola, di ricostruirne i relay precedenti. È proprio la distinzione su cui si fonda la verifica a più hop con i due Spare.

Questo non significa che i pacchetti fossero invisibili: per 38 eventi con hash 0x1F il client USB ha conservato una copia del messaggio cifrato, inclusi i metadati necessari a eventuali analisi successive. Le altre sei ricezioni RF con questo hash non sono documentate nel log da una copia completa del pacchetto utile alla decodifica offline. Ricezione radio, inoltro diagnostico USB e ritrasmissione RF restano fenomeni distinti.

La domanda successiva è immediata: se disponessimo della chiave pubblica corretta soltanto dopo l’acquisizione, potremmo recuperare il contenuto dei pacchetti già registrati?

6. Seconda fase — simulazione offline di MediumFast come SECONDARY

Questa non è una nuova acquisizione radio: è una seconda lettura dei dati già registrati durante la prima. Senza alterare la configurazione della radio e senza acquisire ulteriori messaggi, è stata applicata alle copie cifrate con hash 0x1F la PSK pubblica standard AQ== del canale logico MediumFast, espansa secondo il meccanismo utilizzato da Meshtastic. È stato ricostruito il contatore AES-CTR dai metadati del pacchetto, e i risultati sono stati interpretati come strutture protobuf.

La precedente elaborazione offline ha riportato 38 pacchetti disponibili su 38 decodificati, distribuiti in 14 POSITION_APP, 9 NODEINFO_APP, 12 portnum 70 e 3 portnum 67. Questi dati descrivono soltanto le copie effettivamente recuperabili dal log: non si devono trasformare in 44 decodifiche, né assumere che la decodifica a posteriori equivalga alla configurazione reale del dispositivo durante la ricezione.

Il risultato è significativo: per quei messaggi il limite iniziale era la disponibilità della chiave durante la lettura, non l’assenza del segnale o del payload. Il controllo più importante resta tuttavia ripetere l’acquisizione con il canale davvero dichiarato, lasciando al firmware il compito della decodifica.

7. Terza acquisizione — CUSTOM + MediumFast realmente configurati

Nella terza fase, la radio è stata riconfigurata per dichiarare CUSTOM come PRIMARY e MediumFast con PSK pubblica AQ== come SECONDARY. Il preset radio è rimasto MEDIUM_FAST. In questa nuova sessione l’hash 0x1F è stato associato al canale secondario e il firmware ha effettuato direttamente le decodifiche, prima dell’invio al client USB.

Anche nel terzo test MQTT resta escluso e i flag di uplink/downlink dei canali non sono attivati: l’aggiunta del SECONDARY modifica la capacità di decifrare i pacchetti radio, non introduce un ponte Internet. I risultati della nuova acquisizione devono quindi essere letti come eventi osservati via LoRa.

Sono risultate 102 ricezioni LoRa, delle quali 81 con hash 0x1F; 66 messaggi distinti risultano decodificati sul canale pubblico. Inoltre 10 mittenti di messaggi 0x1F erano già presenti nella prima acquisizione. La coincidenza di hash e il successo della decodifica forniscono insieme una prova più forte del solo hash a 8 bit, che da solo non identifica univocamente un canale.

Il dispositivo ha inoltre completato 38 trasmissioni RF su 0x1F: una volta configurato come canale noto, l’inoltro radio e la lettura diagnostica vanno considerati separatamente. Poiché si tratta di una nuova finestra temporale, i volumi registrati non descrivono un aumento di traffico causato dalla modifica.

8. Confronto delle tre fasi

La prima e la seconda fase condividono la stessa acquisizione; la seconda consiste esclusivamente nella sua rielaborazione offline. Solo la terza è una nuova acquisizione con MediumFast effettivamente presente come SECONDARY. I valori RF della prima e della seconda fase, pertanto, sono identici per definizione. I grafici raffrontano le due sessioni radio reali, mentre la tabella espone tutti e tre gli stadi.

Condizione comune a tutte le fasi: MQTT escluso dal percorso sperimentale. La seconda fase non genera traffico; la prima e la terza confrontano soltanto acquisizioni radio LoRa, pur raccolte in finestre temporali differenti. I 2 e 4 hop relativi a spare_01 e spare_02 appartengono al precedente test controllato e non sono da confondere con i contatori RX qui riportati.

Indicatore	1ª: solo CUSTOM	2ª: decodifica offline 1ª	3ª: CUSTOM + MediumFast
Nuova acquisizione RF	Sì	No	Sì
Canali dichiarati	Solo CUSTOM	Invariati	CUSTOM + MediumFast
Ricezioni LoRa	73	73 (stesso log)	102
Ricezioni radio 0x1F	44	44 (stesso log)	81
Copie cifrate 0x1F recuperabili	38	38	Non pertinente
0x1F decodificati dal firmware	0	0	66
0x1F decodificati offline	Non eseguita	38/38	Non necessario
Mittenti su 0x1F	28	Stessi 28	36
Mittenti comuni fra sessioni RF	—	—	10
Trasmissioni RF su 0x1F	0	0 (nessuna nuova TX)	38

Prima acquisizione — solo CUSTOM

RX LoRa totali

RX con hash 0x1F

0x1F decodificati

Terza acquisizione — CUSTOM + MediumFast

RX LoRa totali

102

RX con hash 0x1F

0x1F decodificati

Stessa scala numerica in entrambi i grafici (massimo: 102). Le ricezioni RF possono comprendere duplicati.

9. Dalla verifica di laboratorio alla rete che utilizziamo ogni giorno

Che cosa cambia, nella pratica, quando più comunità e iniziative condividono una stessa infrastruttura radio?

La forza di una mesh già esistente non consiste solo nel numero di nodi: consiste nelle possibilità di collegamento che può offrire a nuovi gruppi logici, a progetti locali e a servizi specializzati. Un canale dedicato permette di distinguere i destinatari e proteggere i contenuti, mentre una infrastruttura di trasporto condivisa può ampliare le opportunità di raggiungibilità quando le configurazioni degli apparati intermedi lo consentono.

Questo potenziale non è automatico. Nasce dalla consapevolezza dei proprietari e dei gestori dei nodi: conoscere preset e canali, ruoli e limiti del rebroadcast, disponibilità dell’alimentazione, regole operative e impatto delle proprie scelte sulla mesh. Un’armonizzazione ragionata può favorire l’interoperabilità; configurazioni incompatibili o non coordinate possono limitarla. L’obiettivo non è obbligare tutti ad adottare un unico assetto, ma permettere decisioni informate e rispettose delle esigenze locali.

Già nel dossier precedente abbiamo preso come esempio SOS-Italia, una rete logica specializzata che, oltre alle possibilità di collegamento offerte da MQTT, può beneficiare del trasporto radio attraverso l’infrastruttura Meshtastic condivisa, quando le configurazioni dei nodi intermedi lo consentono.

È proprio questa una delle opportunità più interessanti delle reti mesh: consentire a iniziative differenti di sfruttare le potenzialità di un’infrastruttura comune, mantenendo la propria identità logica. Un modello nel quale la conoscenza delle funzionalità, l’armonizzazione delle configurazioni e la collaborazione tra i gestori possono contribuire ad ampliare le possibilità di comunicazione, senza richiedere che ogni iniziativa realizzi autonomamente l’intera infrastruttura di trasporto.

Il riferimento a MQTT, in questo esempio applicativo, descrive una possibilità di collegamento distinta dalla verifica qui documentata: nessuno dei test descritti ha impiegato MQTT. Il transito radio a più hop e l’instradamento attraverso Internet devono essere valutati con metodologie separate.

10. Prima della rete radio, la rete delle persone

Una rete ben armonizzata è più utile quando le sue funzionalità sono spiegate con parole accessibili. Non dovrebbe essere necessario appartenere a una cerchia di specialisti per comprendere la differenza tra canale logico e rete fisica, oppure tra un pacchetto ricevuto, decodificato e ritrasmesso. La documentazione condivisa e il confronto aperto consentono a ciascuno di contribuire con maggiore autonomia.

Occorre soprattutto conservare la volontà di essere curiosi per imparare e la disponibilità a condividere il proprio sapere, compresi dubbi, errori e risultati non attesi. Nessun nodo costituisce da solo una community: si fa rete prima tra le persone, poi come infrastruttura. Questa è una condizione culturale, prima ancora che tecnica, per sostenere progetti credibili e collaborativi.

11. Il merito delle comunità e la responsabilità di riconoscerlo

Un ringraziamento sincero va ai fautori del progetto Meshtastic, agli sviluppatori, ai volontari, ai radioamatori, ai maker e ai gestori indipendenti dei nodi, come pure alle persone che animano ogni Wireless Community Network. Dietro una rete già operativa esistono tempo, competenze, apparati, manutenzione, sperimentazione e disponibilità personale: un contributo reale che non dovrebbe diventare trasparente quando altri servizi ne traggono beneficio.

Per questo il riconoscimento pubblico delle infrastrutture e delle comunità utilizzate dovrebbe essere una normale pratica di correttezza da parte di enti, associazioni, aziende e iniziative che vi si appoggiano. Significa citare con chiarezza il ruolo del trasporto condiviso, ringraziare chi lo rende possibile e non rappresentare come interamente autonome capacità che dipendono, almeno in parte, dall’ecosistema circostante. Si tratta di un principio generale di trasparenza, non dell’attribuzione di un’omissione a un soggetto determinato.

Senza reti interoperabili, le possibilità di comunicazione possono rimanere limitate all’estensione della propria infrastruttura direttamente disponibile. Una rete comunitaria non garantisce automaticamente affidabilità o copertura, ma può creare opportunità che una iniziativa isolata avrebbe maggiori difficoltà a realizzare. Riconoscerlo non riduce il merito delle singole «organizzazioni»: valorizza il lavoro collettivo che consente loro di crescere.

Le osservazioni riportate non intendono certificare, mettere in discussione o ridimensionare le potenzialità delle reti Meshtastic negli scenari di emergenza. La valutazione delle prestazioni in tali contesti richiede verifiche specifiche di disponibilità, consegna dei messaggi, resilienza e comportamento in caso di guasti.

L’intento di questo documento, come delle prove effettuate, è accrescere la consapevolezza che ognuno di noi può contribuire a una rete. Un contributo che nasce prima di tutto dalla curiosità, dalla volontà di imparare e dalla disponibilità a condividere le proprie conoscenze.

Perché fare rete significa, prima ancora di collegare dispositivi, mettere in relazione le persone.

Riferimenti tecnici ufficiali Meshtastic

Fonti: dossier e test CUSTOM precedenti; snapshot Map4 del 19 ottobre 2026; due acquisizioni USB distinte; decodifica offline delle copie cifrate del primo log. Risultati aggregati e anonimizzati.

Una figura trasparente attraversata da collegamenti radio fra nodi di una rete comunitaria

Meshtastic: una rete trasparente, anche nel trasporto

Lascia una risposta

Dossier tecnico-divulgativo · 21 ottobre 2026

Dossier tecnico-divulgativo su interoperabilità radio, ruoli, instradamento e responsabilità condivisa nella rete comunitaria

Un dispositivo radio può contribuire alla consegna di un messaggio cifrato senza poterne leggere una sola parola? È la domanda da cui nasce questo dossier. Non è un giudizio su alcuna rete specializzata, ma un invito a conoscere la parte meno visibile della rete Meshtastic, quella costruita dalla collaborazione tra nodi indipendenti.

Dietro le quinte della mesh: qualche trucco da radio-hacker

La rete sembra invisibile, ma ogni pacchetto lascia indizi: canali, ruoli, hop e ritrasmissioni. Capirli è il primo passo per leggere correttamente un traceroute e configurare il proprio nodo senza alterare inconsapevolmente l’equilibrio della rete comunitaria.

Un canale privato, una rete condivisa

Nell’esperimento condotto due endpoint, qui chiamati spare_01 e spare_02, sono stati configurati con un unico canale logico, CUSTOM, impostato come PRIMARY (indice 0) e protetto da PSK dedicata. Nessuno dei due endpoint aveva il canale MediumFast configurato, né come PRIMARY né come SECONDARY, e nessuno possedeva la relativa PSK pubblica AQ== nella propria configurazione di canale. Altri nodi radio dell’area operavano sul proprio canale MediumFast, senza conoscere la chiave CUSTOM. Le schermate del test documentano ricezioni CUSTOM con 2 hop e, in alcuni casi, 4 hop. Secondo le configurazioni dichiarate, MQTT è disabilitato.

Il risultato dimostra una comunicazione multihop sul canale sperimentale. È coerente con la possibilità che relay radio inoltrino pacchetti di canali di cui non conoscono la PSK. Non identifica però i relay effettivi, né consente di affermare che un particolare nodo della rete Meshtastic abbia necessariamente trasportato ciascun messaggio.

La PSK protegge il contenuto del messaggio, non costituisce di per sé un divieto universale di inoltro. L’assenza del canale pubblico MediumFast sui due endpoint è un elemento centrale del test: i messaggi CUSTOM sono stati ricevuti in multihop senza che gli endpoint partecipassero logicamente al canale pubblico. La prova è coerente con il trasporto trasparente da parte di nodi radio compatibili, ma non identifica gli specifici relay. In un sistema mesh, le decisioni di ritrasmissione dipendono da regole del firmware e metadati di instradamento, oltre che da ruolo del nodo, hop limit, condizioni radio e configurazione di rebroadcast. Un nodo può quindi contribuire alla propagazione di traffico che non è in grado di decifrare.

Il punto che spesso sfugge

Per partecipare e decodificare il canale pubblico italiano MediumFast, occorrono regione EU_868, preset radio MEDIUM_FAST, frequenza/slot coerenti con la comunità, canale PRIMARY pubblico MediumFast e PSK pubblica AQ== (base64 del valore 0x01). La sola coincidenza dei parametri radio consente di ricevere il segnale, non di leggere contenuti cifrati con altre PSK. Il canale pubblico non equivale all’intera rete Meshtastic: possono coesistere canali secondari e mesh private.

Che cosa significa davvero AQ==? Non è un hash SHA, non è un indicatore di due o più bit e non abilita né disabilita il rebroadcast. È la codifica Base64 del byte 0x01: un indice abbreviato di PSK che il firmware espande nella chiave AES-128 pubblica predefinita. Le PSK dei canali possono essere codificate in un byte (indice) oppure contenere una chiave effettiva di 16 o 32 byte. Il pacchetto radio trasporta separatamente un channel hash di 8 bit, ricavato dal nome del canale e dalla PSK, che aiuta il destinatario a individuare la chiave corretta; non è uno SHA crittografico e non governa l’inoltro. L’header radio rimane leggibile anche quando il payload non è decifrabile.

MEDIUM_FAST è il nome di un preset del modem LoRa; MediumFast può essere anche il nome assegnato a un canale applicativo. Non sono la stessa cosa. L’interoperabilità radio richiede parametri fisici compatibili (regione, preset, frequenza effettiva e impostazioni correlate). Nomi di canale diversi non garantiscono isolamento fisico; nomi uguali non garantiscono da soli interoperabilità.

Il test prima delle conclusioni

I due endpoint sono stati utilizzati sulla rete radio Meshtastic italiana nazionale, con regione EU_868 e preset MEDIUM_FAST. Ciascuno dichiarava soltanto CUSTOM come canale PRIMARY (indice 0), con PSK privata condivisa esclusivamente fra i due endpoint; il canale MediumFast non era presente nemmeno come SECONDARY. La documentazione sperimentale riporta MQTT escluso e un relay controllato configurato sul solo canale MediumFast. Lo screenshot LoRa documenta frequency slot 1 e il campo «Override frequency» impostato a 869,525 MHz, frequenza radio effettivamente configurata per il test. Questo dato descrive la configurazione RF utilizzata; non identifica da solo il percorso seguito dai pacchetti né il singolo relay intervenuto.

Osservazione	Interpretazione consentita
Ricezioni CUSTOM con 2 e 4 hop	Il traffico CUSTOM ha raggiunto il destinatario in modalità multihop
Traceroute con intermedi indicati come ffff	Il percorso contiene hop non identificati dall’interfaccia; ffff non prova l’identità dei relay
Percorsi variabili fra gli stessi endpoint	Esistono percorsi osservati differenti o rappresentazioni differenti dei passaggi
Comunicazione presente anche durante LOCAL_ONLY del relay controllato	Non è dimostrata la dipendenza esclusiva da quel relay; possono esistere percorsi alternativi

ALL e LOCAL_ONLY: la scelta che ogni operatore dovrebbe conoscere

Il proprietario del nodo decide come il proprio dispositivo contribuisce alla mesh: non si tratta di un permesso concesso a terzi. Con ALL, un nodo può ritrasmettere anche pacchetti relativi a canali che non conosce, se le altre condizioni di firmware e radio lo consentono. Con LOCAL_ONLY, il proprietario sceglie una ritrasmissione più selettiva rispetto ai canali conosciuti localmente. Non sono impostazioni di cifratura; non assicurano, da sole, né consegna né isolamento assoluto. Nodi preferiti e ruolo possono influenzare le priorità e, in circostanze specifiche, le condizioni di ritrasmissione: un confronto fra ALL e LOCAL_ONLY va quindi letto insieme alla lista dei preferiti, al ruolo e alla versione firmware, senza supporre che il solo interruttore determini ogni passaggio.

L’esperimento di commutazione ALL / LOCAL_ONLY / ALL del relay controllato ha mostrato cambiamenti nei percorsi osservati, ma la presenza di vie alternative impedisce di usare quei soli risultati come prova causale dell’effetto di una singola impostazione. Ripetere la prova senza isolare le alternative non risolverebbe l’incertezza.

I ruoli: non tutti i nodi devono comportarsi da router

La rete funziona meglio quando il ruolo è coerente con posizione, alimentazione e compito del dispositivo. Ogni ruolo è descritto separatamente per distinguere partecipazione, inoltro e funzioni specializzate.

CLIENT — Nodo ordinario: invia, riceve e può ritrasmettere secondo le regole di instradamento; adatto all’uso generale.
CLIENT_MUTE — Comunica ma non ritrasmette il traffico altrui; utile per dispositivi personali e aree radio molto dense.
CLIENT_HIDDEN — Riduce annunci e visibilità, con comportamenti di inoltro più selettivi; non equivale a invisibilità radio assoluta.
CLIENT_BASE — Base personale, anche su installazione fissa: resta un client per le proprie comunicazioni, ma dà priorità ai pacchetti da o verso i nodi preferiti in collegamento diretto, quando le condizioni del protocollo lo consentono.
ROUTER — Infrastruttura radio strategica, ben posizionata e alimentata: anticipa le ritrasmissioni rispetto ai client ordinari; non va scelto automaticamente per ogni nodo.
ROUTER_LATE — Relay infrastrutturale che ritrasmette con ritardo maggiore, riducendo la competizione con altri inoltratori.
REPEATER — Ruolo infrastrutturale con comportamento e visibilità dedicati, ove disponibile nella versione firmware utilizzata.
TRACKER — Orientato alla posizione e alla mobilità; privilegia l’invio di dati di localizzazione.
SENSOR — Orientato a telemetria e misure, spesso con esigenze di risparmio energetico.
TAK / TAK_TRACKER — Ruoli per integrazioni applicative specifiche, ove supportati.

Nota: disponibilità e comportamento esatto dei ruoli possono cambiare fra versioni del firmware Meshtastic e fork indipendenti. La configurazione va sempre verificata sulla versione effettivamente installata.

Il caso CLIENT_BASE è particolarmente istruttivo: un nodo di base può essere client per le proprie comunicazioni e, nello stesso tempo, un punto di distribuzione privilegiato per i propri preferiti in collegamento radio diretto (0 ripetitori intermedi), siano essi dispositivi CLIENT_MUTE, CLIENT_BASE o altri ruoli compatibili. È un paragone funzionale con un router per quel gruppo di nodi, non un’identità tecnica con il ruolo ROUTER. La selezione manuale dei preferiti è prevista nel firmware Meshtastic; la documentazione del fork DarkMesh descrive Auto Zero Cost Hop, che automatizza l’aggiunta di nodi infrastrutturali come preferiti quando anche il nodo locale è infrastrutturale. Questa automazione non garantisce da sola che ogni nodo vicino diventi preferito né modifica le regole generali di CLIENT_BASE.

Collegamenti radio, MQTT e significato degli hop

Un link radio è il passaggio di un pacchetto via etere, direttamente da un dispositivo LoRa a un altro. Non richiede Internet, ma dipende da antenna, distanza, ostacoli, interferenze e configurazioni compatibili. Un link MQTT usa invece una connessione IP e un broker: un gateway può inoltrare messaggi fra mesh geograficamente separate, ma in quel tratto la comunicazione non avviene via radio. Un percorso misto RF/IP non va raccontato come una catena interamente radio. DarkMesh, secondo la documentazione del progetto, è orientato al full-offgrid e non è pensato per un impiego MQTT.

Un messaggio ricevuto direttamente (0 hop intermedi) raggiunge il destinatario senza passare da un ripetitore. Se attraversa un relay, c’è almeno un hop di ritrasmissione; ogni relay ordinario consuma un’unità del contatore disponibile. Attenzione alla terminologia: il valore visualizzato da una specifica app può rappresentare hop effettuati o residui, quindi va letto secondo l’interfaccia e la versione utilizzata.

Il limite dei 7 hop e lo Zero-Cost Hop

Il limite massimo protocollare di 7 hop non è un numero arbitrario: nel pacchetto radio il campo HopLimit occupa 3 bit, che possono rappresentare valori da 0 a 7. Aumentare il numero oltre 7 non è una normale opzione di configurazione; Meshtastic raccomanda generalmente limiti inferiori, salvo necessità verificate, per contenere traffico e collisioni.

Lo Zero-Cost Hop non supera il limite numerico del campo: preserva un hop residuo durante alcune ritrasmissioni tra nodi infrastrutturali preferiti. Secondo la documentazione Meshtastic, la conservazione avviene se il nodo che riceve ha ruolo ROUTER, ROUTER_LATE o CLIENT_BASE, non si tratta del primo hop e il relay precedente risulta tra i preferiti con ruolo ROUTER o ROUTER_LATE. Così una catena di otto o più collegamenti radio fisici può, in condizioni favorevoli, restare entro il budget di sette decrementi. Non è un passaggio gratuito in termini di airtime, né un invito a costruire catene indiscriminate: ogni trasmissione occupa comunque il canale. Il comportamento richiede firmware compatibili e preferiti correttamente configurati.

Meshtastic e DarkMesh: firmware e applicazioni

Il firmware Meshtastic è il riferimento open source che implementa la rete radio e i ruoli documentati ufficialmente. Il firmware DarkMesh è un fork indipendente basato su Meshtastic, con interventi sperimentali aggiuntivi: tra quelli documentati, recupero da condizioni di batteria scarica, Auto Zero Cost Hop e moduli diagnostici. Non è una rete radio separata per definizione: può interoperare con dispositivi Meshtastic quando protocollo, frequenza, preset, canali e funzioni utilizzate sono compatibili. Le modifiche specifiche del fork non devono essere presunte presenti nel firmware ufficiale.

L’app Meshtastic offre le funzioni comuni di gestione nodo, configurazione, messaggistica e consultazione della mesh. L’app Android DarkMesh, anch’essa un fork indipendente, aggiunge funzioni documentate quali messaggi programmati, beacon, rilevamento gateway, risposta ai messaggi, visualizzazione avanzata dei traceroute e strumenti di importazione/esportazione dei nodi. Le due applicazioni possono partecipare alla stessa mesh e scambiarsi i messaggi standard quando i nodi sono configurati in modo compatibile; non occorre che tutti utilizzino la medesima app. L’app DarkMesh comprende anche messaggi compressi utilizzabili non solo con dispositivi che eseguono il firmware DarkMesh, ma anche con dispositivi dotati di firmware Meshtastic, secondo compatibilità. Le funzionalità aggiuntive, i formati di esportazione e le eventuali modalità di decodifica avanzate richiedono comunque una verifica di compatibilità: interoperabilità delle funzioni comuni non significa equivalenza completa delle applicazioni o del firmware.

La configurazione responsabile non consiste nell’impostare ogni nodo come ROUTER: consiste nel capire che cosa serve alla rete circostante, privilegiare l’infrastruttura già disponibile, misurare i risultati e condividere le informazioni. Ogni nodo e l’intera rete operano in best effort: nessuna scelta di ruolo garantisce da sola consegna o copertura.

Cinque curiosità utili per il proprio nodo

Preset radio — quale configurazione LoRa usa davvero? Verificare in LoRa il valore effettivo del modem preset. Per partecipare alla rete comunitaria italiana descritta in questo dossier occorre utilizzare MEDIUM_FAST, dove adottato localmente: non confonderlo con il nome del canale MediumFast. Il firmware può anche avere impostazioni predefinite differenti, perciò è importante conoscere quelle effettivamente condivise dai nodi della propria area.
Frequenza — su quale frequenza trasmette? Verificare la regione EU_868, il frequency slot e l’eventuale override; per l’interoperabilità devono coincidere i parametri radio effettivi. Nei materiali sperimentali compaiono slot 1 e 869,525 MHz, ma la sola schermata non dimostra l’applicazione dell’override. Rispettare sempre i vincoli radio vigenti.
Canali — quali indici e chiavi sono configurati? Controllare il PRIMARY (indice 0) e gli eventuali SECONDARY (indici 1–7). Nella configurazione pubblica MediumFast esaminata, la PSK è AQ==; i canali privati utilizzano chiavi dedicate. La PSK determina la possibilità di decifrare i contenuti, non necessariamente quella di inoltrare il pacchetto.
Rebroadcast — come contribuisce il nodo alla rete? ALL può ritrasmettere pacchetti di altre mesh con impostazioni radio compatibili, anche senza decifrarli; LOCAL_ONLY limita l’inoltro ai canali locali riconosciuti. Verificare anche il ruolo del dispositivo e l’hop limit. Evitare modifiche indiscriminate: comprenderne prima l’effetto sulla rete comunitaria.
MQTT — il traffico resta via radio? Controllare l’attivazione del modulo MQTT, dell’eventuale proxy e di uplink/downlink per ciascun canale. Un gateway può introdurre percorsi IP, diversi dai soli hop radio. Per una prova puramente RF, documentare MQTT disabilitato e verificare la configurazione degli altri nodi coinvolti.

Queste verifiche sono un invito alla consapevolezza tecnica del proprietario/gestore, non una prescrizione a riconfigurare i nodi altrui o ad abbandonare i parametri condivisi della comunità.

Una rete comunitaria, molti percorsi possibili

La rete comunitaria Meshtastic già presente sul territorio costituisce un patrimonio distribuito di infrastrutture, sperimentazione e conoscenza condivisa. La rete Meshtastic italiana non è una singola catena di ripetitori né una dorsale gestita da un solo soggetto. È una costellazione mutevole di nodi installati da cittadini, radioamatori, sperimentatori e gruppi locali: tetti, alture, postazioni fisse e dispositivi mobili creano percorsi alternativi, talvolta asimmetrici, che cambiano con propagazione, traffico e disponibilità dei relay. Un messaggio può percorrere due hop in un momento e quattro in un altro; la stessa destinazione può essere raggiunta da vie diverse. I traceroute mostrano percorsi osservati, non un catalogo esaustivo di tutti i relay disponibili.

La mappa interattiva LoRaCity (https://maps.loracity.it/) documenta nodi e collegamenti osservati attraverso i traceroute. Qui sotto è riportata una rappresentazione grafica dell’estrazione nazionale della rete Meshtastic, elaborata dai dati pubblici LoRaCity: 1.165 nodi geolocalizzati e 1.666 segmenti geografici distinti nel campione acquisito. È una fotografia parziale e dinamica, non una certificazione di copertura continua o di disponibilità del servizio.

Mappa nazionale dei nodi e dei collegamenti radio osservati da LoRaCity — Rete comunitaria Meshtastic italiana: 1.165 nodi geolocalizzati e 1.666 segmenti distinti osservati nel campione LoRaCity. Non è una mappa di copertura garantita.

Dal laboratorio al territorio: il caso SOS-Italia

Il test CUSTOM introduce una questione di portata più generale: una rete specializzata può beneficiare del trasporto offerto da nodi indipendenti, senza che i loro proprietari condividano il canale applicativo o la chiave dei messaggi. Questo è un effetto tecnico possibile dell’interoperabilità, non una prova di appartenenza organizzativa, consenso esplicito o proprietà dell’infrastruttura.

SOS-Italia è qui soltanto un esempio su larga scala perché la sua rappresentazione pubblica Map4 consente di esaminare le sovrapposizioni con i nodi che dichiarano MediumFast; il fenomeno tecnico può riguardare qualunque rete o soggetto terzo. Il punto editoriale non è negare il valore di procedure, operatori o servizi dedicati alle emergenze: è chiedere che la comunicazione pubblica distingua con precisione copertura propria, interoperabilità con nodi terzi, connettività osservata e capacità effettivamente garantita.

Trasparenza: cosa sarebbe utile dichiarare

Ogni progetto che utilizza o può utilizzare un ecosistema radio condiviso potrebbe spiegare, in linguaggio comprensibile, che i relay di terzi possono contribuire alla propagazione anche di pacchetti non decifrabili; che l’operatore del relay conserva il controllo della propria configurazione; e che tale contributo non equivale ad adesione a progetti diversi né a garanzia di servizio.

Questa è una raccomandazione generale di chiarezza rivolta a chiunque utilizzi o descriva una rete radio condivisa. Qualunque gruppo, progetto o singolo utilizzatore potrebbe beneficiare, in presenza di configurazioni compatibili, della rete comunitaria già esistente come infrastruttura di trasporto trasparente, senza che i proprietari dei relay possano necessariamente leggere i messaggi o conoscano il progetto che ne beneficia. La possibilità tecnica non dimostra l’effettivo percorso di uno specifico pacchetto né un’adesione degli operatori. Nel caso di comunicazioni su attività di emergenza, chiarezza e prudenza sono tanto più importanti proprio per rispetto delle persone coinvolte e delle conseguenze concrete di eventuali mancate comunicazioni: questo dossier non ne mette in discussione il valore o la sofferenza.

E se molti nodi passassero a LOCAL_ONLY?

La conseguenza ipotetica è intuitiva: riducendo l’inoltro di pacchetti di canali sconosciuti, una parte delle vie disponibili per le reti specializzate potrebbe venire meno. L’entità reale dipenderebbe da quali nodi modificano l’impostazione, dai canali che conoscono, dalla distribuzione dei percorsi, dal ruolo dei dispositivi e dall’evoluzione radio nel tempo.

Per evitare di trasformare questa ipotesi in una previsione arbitraria, l’analisi topologica usa un esperimento diverso: prende la topologia di adiacenze osservata in Map4 e rimuove virtualmente i nodi classificati «appartenenti alla rete Meshtastic». È uno scenario più drastico e diverso da un passaggio collettivo a LOCAL_ONLY: i nodi rimossi spariscono completamente dal grafo, mentre LOCAL_ONLY può lasciare disponibili alcuni inoltri e tutte le altre funzioni del nodo.

La fotografia nazionale e la simulazione

Fonte: esportazione delle API pubbliche Map4, raccolta il 19 ottobre 2026; finestra neighbor richiesta 168 ore. Dataset descrittivo, non certificazione operativa.

Indicatore	Valore acquisito
Nodi censiti	927
Nodi della rete Meshtastic senza SOS-Italia dichiarato	772 (83,3%)
Nodi MediumFast + SOS-Italia	145 (15,6%)
Nodi SOS-Italia senza MediumFast	10 (1,1%)
Risposte neighbor riuscite / interrogate	922 / 927
Record neighbor acquisiti	825
Coppie di adiacenza distinte fra nodi censiti	331
Adiacenze tra nodi SOS e nodi della rete Meshtastic	74
Nodi censiti con almeno un collegamento riportato	215 / 927

Il risultato della rimozione virtuale

Connettività fra nodi SOS nel grafo	Coppie reciprocamente raggiungibili
Grafo completo osservato	2.237
Senza i 772 nodi classificati come nodi della rete Meshtastic	1.923
Differenza	−314 coppie (−14,0%)

La metrica conta le coppie non ordinate di nodi che dichiarano SOS-Italia e appartengono alla stessa componente connessa di un grafo non orientato. Non misura consegne di pacchetti, percentuali di messaggi persi, estensione territoriale, uptime o prestazioni durante un’emergenza.

La simulazione indica che, nella fotografia di adiacenze disponibile, alcuni nodi classificati come nodi della rete Meshtastic contribuiscono a connettere fra loro nodi che dichiarano SOS-Italia. Non significa che LOCAL_ONLY comporterebbe una perdita del 14% della copertura SOS-Italia. Significa che esiste una dipendenza topologica potenziale, degna di misurazioni RF più rigorose.

Una rete vista dalla mappa non è tutta la rete

Incrocio esplorativo delle due raccolte: LoRaCity comprende 1.692 identificativi di nodo; lo snapshot SOS-Italia utilizzato per l’incrocio ne contiene 922. 670 identificativi coincidono esattamente; fra questi, 560 hanno coordinate valorizzate nel censimento LoRaCity e 45 dichiarano il canale SOS-Italia nello snapshot esaminato. Il conteggio degli identificativi distinti nell’unione è 1.944 (1.692 + 922 − 670): non va confuso con il numero di nodi simultaneamente attivi o geolocalizzati.

Incrociando i segmenti geografici LoRaCity con le coppie di adiacenza Map4 per coordinate arrotondate a due decimali, emergono 58 corrispondenze geografiche fra 298 coppie Map4 con coordinate disponibili. È un riscontro approssimativo fra fotografie e fonti diverse, non 58 link radio indipendentemente certificati: nodi vicini, arrotondamenti, timestamp e diversa origine dei dati possono produrre falsi abbinamenti. La correlazione rigorosa richiede identificativi di entrambi gli estremi, timestamp coerenti e conferma RF del collegamento.

Soltanto 215 dei 927 nodi compaiono in almeno un collegamento neighbor fra nodi censiti. Cinque interrogazioni neighbor hanno restituito HTTP 404; 164 record puntano a peer esterni al censimento. I timestamp contengono anomalie da verificare. Le adiacenze riportate non certificano percorsi reali dei messaggi e non distinguono in modo definitivo contributi RF e MQTT.

Cosa possiamo affermare, cosa resta da verificare

Accertato nei materiali esaminati: l’esperimento documenta comunicazioni CUSTOM multihop; l’analisi nazionale documenta una forte sovrapposizione fra nodi censiti e MediumFast, oltre a 74 adiacenze fra nodi che dichiarano SOS-Italia e nodi classificati come nodi della rete Meshtastic. La rimozione virtuale di questi ultimi riduce del 14,0% le coppie SOS connesse nel grafo osservato.

Non accertato: il relay specifico di ciascun pacchetto CUSTOM; la proprietà organizzativa dei nodi censiti; la quota di traffico SOS effettivamente trasportata da relay indipendenti; la perdita reale di servizio in uno scenario LOCAL_ONLY; la capacità operativa in emergenza; l’identità dei relay effettivi in assenza di log sincronizzati.

Prima conclusione tecnica: in una mesh con canale primario condiviso, chiave pubblica e inoltro trasparente, un nodo configurato per il rebroadcast ALL può contribuire alla propagazione di pacchetti che non sa decifrare. Il rebroadcast ordinario è previsto dal protocollo e può avvenire senza accordi fra proprietari di nodi. Non significa che ogni nodo inoltri ogni pacchetto: ruoli, preferiti, deduplicazione, limiti di hop, occupazione del canale e condizioni radio intervengono nella decisione. Nella rete comunitaria esistente, con molti percorsi alternativi, l’attribuzione precisa di ogni inoltro è difficile; per stabilire un nesso causale occorrono prove RF controllate, non necessariamente un ambiente totalmente privo di altri segnali.

Come trasformare l’ipotesi in una misura

Servono osservazioni temporali sincronizzate di trasmissione e ricezione, log diagnostici dei relay disponibili, verifica dei parametri RF effettivi, ripetizioni con topologie controllate o percorsi alternativi esclusi, confronto fra ALL e LOCAL_ONLY a parità di ruolo e lista dei nodi preferiti, prove con e senza preferred router/Zero-Cost Hop, e misure di consegna per canale. Una nuova fotografia nazionale dovrebbe inoltre validare i timestamp, distinguere le osservazioni recenti da quelle storiche e separare la connettività radio da eventuali ponti IP.

La responsabilità condivisa della conoscenza

Per operatore Meshtastic si intende qui il proprietario o gestore del singolo nodo radio, che ne cura installazione, configurazione e funzionamento: non necessariamente un membro o rappresentante di un’organizzazione. Gli operatori Meshtastic dovrebbero sapere che una scelta come ALL può favorire il trasporto di traffico cifrato che non leggono. Le reti specializzate dovrebbero descrivere con chiarezza quando la propria connettività si avvale, anche potenzialmente, di infrastrutture comunitarie non controllate. La trasparenza non sminuisce nessuno: permette a utenti, volontari e organizzazioni di valutare meglio autonomia, resilienza e limiti delle reti.

La rete comunitaria già esistente è una risorsa collettiva costruita nel tempo grazie a iniziative autonome: conoscerla e riconoscerne il contributo è essenziale prima di descrivere l’estensione di una rete specializzata. Informazione corretta e conoscenza condivisa permettono a ciascun proprietario/gestore di valutare il comportamento del proprio nodo e gli effetti delle impostazioni sull’ecosistema. Meshtastic resta un progetto fortemente sperimentale: propagazione, percorsi e disponibilità variano, e sia il singolo nodo sia la rete nel complesso operano in best effort, senza garanzia di consegna, continuità, copertura o prestazioni d’emergenza.

Fonti e metodologia

Esperimento: dossier sperimentale CUSTOM del 20 ottobre 2026 e schermate fornite durante i test. Analisi nazionale: snapshot Map4 del 19 ottobre 2026 (https://sos-italia.net/map4/); audit tecnico topologico; SOS_Italia_analisi.json; archivio neighbor integrale. I nomi dei dispositivi sperimentali sono anonimizzati come spare_01 e spare_02. Il canale sperimentale è CUSTOM. I dati aggregati dell’analisi nazionale restano distinti dai test controllati.

Ripetibilità e accessibilità: l’esperimento è stato eseguito da un semplice utente, senza accesso privilegiato all’infrastruttura. Il metodo può essere ripetuto da altri utenti utilizzando i dati pubblicamente visibili nella mesh e quelli resi disponibili online. Internet ha consentito una raccolta più rapida e su scala nazionale; la raccolta esclusivamente radio è anch’essa possibile, ma limitata ai nodi e ai collegamenti effettivamente raggiungibili nella mesh e al vincolo ordinario del campo hop limit (massimo 7, salvo i meccanismi Zero-Cost Hop applicabili). La ripetibilità del metodo non implica risultati identici: topologia, propagazione, traffico e timestamp cambiano nel tempo.

Nota editoriale: documento tecnico-divulgativo indipendente. Non costituisce certificazione di rete d’emergenza, attribuzione di responsabilità né valutazione legale di comunicazioni di terzi.

Infografica dell’analisi topologica Map4 sul caso SOS-Italia — Infografica conclusiva dell’analisi topologica Map4 del 19 ottobre 2026: simulazione su un grafo osservato, non prova del percorso effettivo dei messaggi.

Riferimenti tecnici e cartografici

Cifratura, PSK pubblica e inoltro senza decifratura: https://meshtastic.org/docs/overview/encryption/
PSK abbreviata, channel hash e protocollo: https://github.com/meshtastic/meshtastic-sdk/blob/main/docs/protocol.md
Ruoli Meshtastic: https://meshtastic.org/docs/configuration/radio/device/
Algoritmo di trasporto e campo HopLimit: https://meshtastic.org/docs/overview/mesh-algo/
Zero-Cost Hops, condizioni e limiti: https://meshtastic.org/blog/zero-cost-hops-favorite-routers/
MQTT e policy dei gateway: https://meshtastic.org/docs/software/integrations/mqtt/
DarkMesh, documentazione del fork e delle app: https://darkmesh.neocities.org/
Documentazione Meshtastic, consigli di configurazione: https://meshtastic.org/docs/configuration/tips/
Documentazione Meshtastic, accesso alla mesh locale: https://meshtastic.org/docs/getting-started/joining-your-local-mesh/
Documentazione Meshtastic, impostazioni radio: https://meshtastic.org/docs/overview/radio-settings/
Riferimento comunitario italiano: https://www.meshtasticitalia.it/
Mappa LoRaCity, nodi e traceroute osservati: https://maps.loracity.it/
Analisi Map4: snapshot del 19 ottobre 2026: https://sos-italia.net/map4/ e infografica conclusiva fornita per questo dossier.

↓ Scarica il dossier in formato PDF

Versione integrale del dossier in formato PDF · Google Drive