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.

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.

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.

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

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.