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.

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.

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.

Il risultato della rimozione virtuale

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.

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.