Se utilizzi MeshCore da un po’, avrai sicuramente notato path.hash.mode nella CLI e ti sei chiesto cosa faccia concretamente. Forse l’hai visto comparire nel changelog della v1.14.0 come «supporto multi-byte per path hash» e sei andato avanti. O forse stai riscontrando strani problemi di routing — messaggi consegnati al repeater sbagliato, percorsi che funzionano un giorno e si rompono il giorno dopo — senza renderti conto che il problema è inscritto nella matematica.
I path hash sono il meccanismo con cui i pacchetti trovano la strada attraverso la mesh, e la dimensione di questi hash determina se la rete può scalare oltre qualche decina di repeater senza interferenze. Questa guida spiega come funzionano, quando è importante intervenire, e come riconoscere quando la tua mesh ha superato il limite predefinito.
Cosa fanno i path hash
Ogni volta che un pacchetto si propaga attraverso la mesh, raccoglie delle briciole di pane. Ogni repeater che lo inoltra aggiunge un breve identificatore — il suo path hash — al campo path del pacchetto prima di ritrasmettere. Quando il pacchetto arriva a destinazione, il campo path contiene la traccia completa di ogni repeater attraversato.
Questa traccia è il punto centrale del meccanismo. Quando il dispositivo destinatario invia una risposta, non deve fare un nuovo flood della rete: ha già il percorso. Il campo path del pacchetto in arrivo gli dice esattamente quali repeater usare, nell’ordine corretto, per tornare dal mittente originale.
Questo è ciò che rende il routing di MeshCore fondamentalmente diverso dai sistemi solo-flood. Il primo messaggio viene floodato; tutti i successivi seguono direttamente il percorso appreso. Nessuna ritrasmissione ridondante, nessun airtime sprecato.
Cos'è l'hash
Il path hash di ogni repeater corrisponde ai primi N byte della sua chiave pubblica — non un hash
del percorso in sé, ma un’impronta digitale dell’identità del repeater, troncata per stare all’interno del pacchetto senza consumare tutto il budget di payload.
La domanda è: quanti byte usare per questa impronta. È questo che controlla path.hash.mode.
Il campo path in un pacchetto MeshCore ha un limite massimo di 64 byte.
Poiché ogni hop occupa N byte, la dimensione dell’hash controlla direttamente quanti hop un pacchetto può attraversare.
Perché la modalità 1 byte si rompe su reti grandi
Con soli 254 ID utilizzabili, le collisioni non sono soltanto possibili — sono matematicamente inevitabili una volta che la mesh supera una certa dimensione. Con 20 repeater, la probabilità che due condividano lo stesso prefisso a un byte è già significativa. Con 50, è più probabile che no.
Oltre 100, le collisioni sono garantite nella maggior parte delle reti. Le collisioni non sono un problema estetico. Quando due repeater condividono lo stesso hash a 1 byte, entrambi risponderanno ai pacchetti direct-routed indirizzati a quel prefisso. Il Repeater A vede un pacchetto con il suo hash in testa al percorso, lo toglie e inoltra il pacchetto — anche se il percorso era stato costruito attraverso il Repeater B. Il pacchetto va nella direzione sbagliata, e il mittente non riceverà mai una risposta. O peggio, entrambi i repeater inoltrano il pacchetto, generando duplicati che rimbalzano attraverso la mesh.
La rete ceca ha incontrato questo problema duramente: nel 2026 ha superato i 255 repeater, più nodi univoci di quanti la modalità 1 byte possa anche solo rappresentare. Le discussioni GitHub (#1613) hanno evidenziato la geometria: con un range di 50 km e soli 256 identificatori, ogni ID copre circa 30 km² — un cerchio con raggio di 3 km. In qualsiasi area popolata, non è sufficiente.
Prima del supporto multi-byte, la soluzione era il coordinamento manuale. La rete di Ottawa gestiva un foglio di calcolo con tutti i 256 ID. Gli operatori usavano strumenti di keygen per generare chiavi pubbliche con specifici prefissi al primo byte. Alcune comunità riservavano interi blocchi dello spazio ID per i link backbone. Funzionava, appena, e solo perché qualcuno ci stava dietro. Non era destinato a scalare.
Come viene codificato il pacchetto
Le informazioni sul percorso risiedono in un singolo byte path_length, compresso a bit:
• Bit 0–5: conteggio degli hop (0–63)
• Bit 6–7: dimensione dell’hash, codificata come (hash_size – 1)
Esempi:
0x05 = 5 hop, hash 1 byte → 5 byte di dati percorso
0x45 = 5 hop, hash 2 byte → 10 byte di dati percorso
0x8A = 10 hop, hash 3 byte → 30 byte di dati percorso
Questa codifica significa che il ricevitore sa sempre come interpretare il percorso. Legge la dimensione dell’hash dai bit superiori e il c conteggio degli hop da quelli inferiori. Nessuna ambiguità, nessuna negoziazione.
Segnali che la tua mesh ha superato la modalità 1 byte
Non riceverai sempre un messaggio di errore chiaro. Le collisioni di hash creano sintomi che sembrano altri problemi.
Cosa osservare:
• Messaggi che funzionano un giorno e falliscono il successivo. Se un percorso direct-routed funziona a volte ma cade in modo casuale, una collisione potrebbe instradare i pacchetti attraverso il repeater sbagliato.
• Percorsi attraverso repeater inattesi. Se i tuoi strumenti mostrano pacchetti che prendono rotte geograficamente illogiche, due repeater con lo stesso hash a 1 byte potrebbero confondere il path builder.
• ACK che non tornano mai. Invii un messaggio diretto, il percorso sembra corretto in uscita, ma l’ACK non arriva mai. Una collisione sul percorso di ritorno fa sì che un repeater sbagliato si appropri del pacchetto.
• Numero crescente di repeater. Se la tua mesh regionale ha più di 30–40 repeater in portata reciproca, le collisioni sono statisticamente probabili. Oltre 80–100, sono quasi certe. Non aspettare i sintomi: la matematica dice già che è il momento.
• Strumenti di mapping mostrano percorsi ambigui. Strumenti come LetsMesh Analyzer e MeshMapper si basano sui dati dei path hash per tracciare i percorsi. Con le collisioni a 1 byte, questi strumenti non riescono a distinguere in modo affidabile due repeater con lo stesso prefisso.
• La tua comunità coordina manualmente i prefissi. Se gli operatori scelgono le chiavi per evitare collisioni a mano, è il segnale più chiaro che il sistema ha bisogno di uno spazio di
indirizzamento più grande.
Come effettuare il passaggio
Verifica il firmware
Il supporto multi-byte per i path hash richiede firmware v1.14.0 o successivo su tutti i repeater nel percorso. I repeater con firmware precedente ignorano silenziosamente i pacchetti con hash a 2 o 3 byte — nessun errore, nessun NACK, scompaiono e basta.
I repeater su v1.14.0+ inoltrano tutte e tre le dimensioni di hash indipendentemente dalla loro impostazione path.hash.mode. La modalità controlla solo quale dimensione il repeater usa nei propri annunci. È quindi possibile aggiornare i repeater progressivamente.
Configurazione sul repeater
Connettiti via USB seriale o via web config e usa i seguenti comandi:
set path.hash.mode 1 # hash 2 byte
set path.hash.mode 2 # hash 3 byte
get path.hash.mode # verifica impostazione attuale
advert # riannuncia per aggiornare la rete
Configurazione sul companion
Nell’app MeshCore (v1.41.0+), vai in Impostazioni → Impostazioni sperimentali e modifica la dimensione preferita del path hash. L’app mostra anche le informazioni sull’hash nella schermata dei dettagli contatto.
Il periodo di transizione
Durante la migrazione, aspettati una rete mista. Alcuni repeater annunceranno hash a 1 byte, altri a 2. Va bene: i repeater v1.14.0+ inoltrano tutte le dimensioni. Il percorso di migrazione pratico:
1. Aggiorna tutti i repeater al firmware v1.14.0+ per primo
2. Passa i repeater a path.hash.mode 1 (2 byte) man mano che li aggiorni
3. Quando la massa critica di repeater è su v1.14.0+, aggiorna i companion
4. Monitora eventuali percorsi che si rompono: indicano repeater ancora da aggiornare
Quale modalità scegliere
Mantieni 1 byte se:
la tua mesh è piccola (meno di 30 repeater in portata), dipendi da catene di hop molto lunghe (40+hop per backhaul), o la tua regione non ha ancora finito di aggiornare i repeater a v1.14.0+.
Scegli 2 byte per la maggior parte delle reti:
È il punto di equilibrio raccomandato dalla comunità. Si passa da 254 ID a 65.536 — sufficiente per qualsiasi mesh regionale prevedibile — riducendo il massimo di hop da 64 a 32. La grande maggioranza dei percorsi reali resta sotto i 25 hop.
Considera 3 byte solo per:
deployment su scala molto grande, con centinaia o migliaia di repeater in aree dense dove anche 65k ID potrebbero eventualmente collidere. Il limite di 21 hop è un vero vincolo da valutare prima.
Il quadro generale
L’hashing del percorso è uno di quei dettagli che non conta affatto finché improvvisamente conta moltissimo. Una mesh con cinque repeater e hash a 1 byte funziona perfettamente. Una mesh con 80 repeater e hash a 1 byte ha bug di routing invisibili quasi impossibili da diagnosticare senza conoscere le collisioni.
L’introduzione del multi-byte path hash nella v1.14.0 è stato uno dei cambiamenti di scaling più importanti che MeshCore abbia mai fatto. Non aggiunge nuove funzionalità — rimuove un soffitto.
Per qualsiasi mesh comunitaria che voglia crescere seriamente, rimuovere i soffitti presto è sempre meno costoso che affrontare i problemi che creano in seguito.
Se non hai ancora controllato il tuo path.hash.mode, questo è il momento giusto. Esegui get path.hash.mode sui tuoi repeater. Se sono su 0 e la mesh sta crescendo, considera di passare a 1. Il cambio richiede un solo comando, il miglioramento è permanente, e il costo del non farlo aumenta con ogni repeater che aggiungi.
Articolo di Rolfy HB9ODI
