MeshCore i path.hash.mode: co dają 2 i 3 bajty w repeaterze i companionie

Temat na ten artykuł podsunął nam czytelnik poprzez formularz Zaproponuj temat. Zwrócił on uwagę, że dużo się obecnie mówi o przestawianiu companionów na dłuższe identyfikatory, ale trudno znaleźć jasne i przekonujące wyjaśnienie, co to tak właściwie nam daje. Spróbujmy to więc wyjaśnić od podstaw, bez zakładania, że ktoś zna budowę pakietu MeshCore. Na końcu tekstu zebraliśmy krótką listę argumentów odpowiadających na pytanie: „po co mam to zmieniać?”.

Najpierw małe wyjaśnienie, bo numeracja w poleceniu zmieniającym to ustawienie łatwo może wprowadzić w błąd. Liczba po set path.hash.mode to liczba bajtów pomniejszona o jeden:

Teraz możemy ruszać dalej.

Jak MeshCore rozsyła wiadomości

Wiadomość wędruje przez radio w pakiecie, czyli w porcji danych. Po drodze przekazują ją repeatery (przemienniki), czyli urządzenia, które słuchają eteru i powtarzają cudze pakiety. Twój companion, czyli radio, z którego korzystasz przez aplikację w telefonie, jak pewnie wiesz, domyślnie niczego dalej nie przekazuje.

Większość ruchu rozchodzi się sposobem, który dokumentacja nazywa z angielska flood (ang. zalanie, powódź). Działa to jak plotka w małym miasteczku: każdy repeater, który usłyszy nowy pakiet, powtarza go raz, a jego sąsiedzi robią to samo. Po chwili pakiet dociera wszędzie, dokąd sięga sieć. Tak rozchodzą się wiadomości na kanałach, ogłoszenia, którymi urządzenia dają znać o swoim istnieniu (advert), i pierwsza wiadomość prywatna do nowego kontaktu.

Taki sposób jest skuteczny, ale dość rozrzutny, bo ten sam pakiet nadaje po kolei, często niepotrzebnie, wiele repeaterów. Dlatego wiadomości prywatne, gdy trasa do odbiorcy jest już znana, jadą inaczej: tylko przez wskazane repeatery. Trochę jak autobus, który zatrzymuje się wyłącznie na przystankach z rozkładu. Ten tryb nazywa się direct. Żeby jednak wiedzieć, którędy jechać, trzeba najpierw poznać trasę.

Ślad, który zbiera każdy pakiet

Każdy repeater, który przekazuje pakiet w trybie przekazywaniaflood, dopisuje do niego swój identyfikator. Po kilku skokach pakiet niesie więc listę repeaterów, przez które przeszedł, tak jak paszport zbiera pieczątki z kolejnych przejść granicznych. W tekście nazywamy tę listę śladem trasy (w dokumentacji path).

Identyfikatora nikt nie przydziela. Każde urządzenie MeshCore ma parę kluczy do szyfrowania, a klucz publiczny jest jego jawną wizytówką: ciągiem 32 bajtów, który repeater dostaje po instalacji oprogramowania (firmware), przy pierwszym uruchomieniu. Cały klucz nie zmieściłby się w śladzie wiadomości, przechodzącej przez wiele repeaterów, więc trafia tam tylko jego początek: pierwszy bajt (dwa znaki z zapisie szesnastkowym), a po zmianie ustawienia - dwa albo trzy. Ten skrawek klucza dokumentacja nazywa path hash i stąd właśnie wzięła się nazwa polecenia: path.hash.mode.

Ślad bardzo się przydaje w komunikacji bezpośredniej. Odbiorca wiadomości prywatnej odsyła go nadawcy i od tej chwili kolejne wiadomości są wysyłane w trybie direct, wyznaczoną trasą. Repeater, który usłyszy taki pakiet, patrzy tylko na pierwszy identyfikator z listy. Jeśli to jego, skreśla go i nadaje pakiet dalej. Jeśli nie - milczy. Dzięki temu komunikacja bezpośrednia między dwoma urządzeniami nie zalewa całej sieci, a idzie po ściśle uzgodnionej ścieżce.

Z tego samego śladu korzysta aplikacja, kiedy pokazuje, którędy przyszła wiadomość, a także analizatory sieci. Analizator analyzer.marwoj.net, zbudowany na oprogramowaniu CoreScope, rysuje na jego podstawie trasy pakietów, mapę połączeń między repeaterami i statystyki ich pracy.

Dlaczego jeden bajt to za mało

Identyfikator zapisany na jednym bajcie może przyjąć tylko 256 różnych wartości, od 00 do FF (tak zapisuje się bajty w systemie szesnastkowym). W praktyce repeatery korzystają z 254, bo przy tworzeniu klucza omijają skrajne wartości - 00 i FF. W Polsce działają tysiące repeaterów, więc wiele z nich musi mieć ten sam identyfikator. Kłopoty zaczynają się jednak znacznie wcześniej, niż podpowiada intuicja.

Działa tu znany paradoks dnia urodzin: w grupie zaledwie 23 osób szansa, że dwie z nich obchodzą urodziny tego samego dnia miesiąca, przekracza 50%. Z repeaterami jest podobnie. Jeśli z jednego miejsca słychać 30 repeaterów, to w 83 przypadkach na 100 co najmniej dwa z nich mają ten sam jednobajtowy identyfikator. Przy stu repeaterach jest to już praktycznie pewne.

Dwa bajty z kolei dają 65 536 możliwych wartości, a trzy - ponad 16 milionów. Wśród tych samych 30 repeaterów szansa na powtórkę spada przy dwóch bajtach do 0,7%. Nawet w całym regionie Warszawa, gdzie MeshMapper widzi 468 repeaterów, dwa bajty dają średnio niecałe dwie pary z tym samym identyfikatorem. Przy jednym bajcie takich par byłoby ponad czterysta.

Rachunek zgadza się z tym, co widać w polskiej sieci. 25 października 2026 roku analizator analyzer.marwoj.net znał 651 repeaterów, które ogłaszają się z identyfikatorem jednobajtowym. Zajęły one 237 z 256 możliwych wartości, a 191 z tych wartości ma więcej niż jednego właściciela. Przy 122 identyfikatorach właścicieli jest trzech lub więcej, a rekordzista należy do ośmiu repeaterów. Wśród 983 repeaterów z identyfikatorem dwubajtowym powtórek było siedem, a wśród 330 z trzybajtowym nie było żadnej.

Co się psuje, gdy dwa repeatery mają ten sam identyfikator

Najbardziej cierpią wiadomości prywatne. Wyobraź sobie, że trasa do kolegi prowadzi przez repeater A3, a w okolicy stoi drugi repeater, który przypadkiem też ma identyfikator A3. Oba słyszą twoją wiadomość, oba uznają, że trasa prowadzi przez nie, i oba ją nadają. Wiadomość trafia wtedy także tam, gdzie nie powinna, w eterze robi się tłoczniej, a dwie niemal jednoczesne transmisje mogą się nawzajem zagłuszyć u następnego repeatera. To właśnie może być jedną z przyczyn, dlaczego wiadomości raz dochodzą, a raz nie, a potwierdzenia odbioru (ACK), niezbędne w komunikacji bezpośredniej - nie wracają do nadawcy.

W polskiej sieci takie sąsiedztwo zdarza się bardzo często. Według współrzędnych geograficznych uzyskiwanych z ogłoszeń (advert) w 35 przypadkach dwa albo więcej repeaterów z tym samym jednobajtowym identyfikatorem stoi bliżej niż 50 km od siebie. Mogą więc słyszeć te same nadajniki i wchodzić sobie w drogę, i często to właśnie robią.

Drugi kłopot dotyczy diagnostyki. Przy jednym bajcie ani aplikacja, ani analizator nie wiedzą na pewno, który repeater na przykład o identyfikatorze A3 był na trasie pakietu. Analizator próbuje to zgadnąć z całego śladu i z położenia repeaterów, ale coraz rzadziej trafia. Wtedy linia na mapie łączy nie te repeatery, co trzeba, a operator szukający słabego ogniwa idzie fałszywym tropem. W analizatorze repeatery dzielące ten sam identyfikator pokazuje zakładka Analytics → Hash Issues, a zakładka Prefix Tool pozwala sprawdzić, czy dany początek klucza jest jeszcze wolny. Jak czytać te zakładki, opisaliśmy w tekście o CoreScope Analytics.

Trzecia problem jest mniej znany: ochrona przed pętlami. Wadliwy firmware potrafi sprawić, że pakiet zaczyna krążyć w kółko, a powtarzają go dziesiątki repeaterów. Od wersji 1.14 repeater umie to rozpoznać (ustawienie loop.detect): jeśli w śladzie pakietu widzi swój identyfikator zbyt wiele razy, odrzuca go. Przy jednym bajcie musi być jednak bardzo pobłażliwy, bo ten sam identyfikator mogą mieć przecież inne urządzenia. W trybie minimal, domyślnym w nowych instalacjach od wersji 1.18, reaguje on dopiero wtedy, gdy znajdzie go w śladzie cztery razy. Przy dwóch bajtach wystarczą dwa razy, a przy trzech - jeden. Dłuższy identyfikator pozwala więc wyłapać pętlę wcześniej i bez ryzyka, że repeater odrzuci zdrowy pakiet.

Kto decyduje o długości identyfikatora

Tu leży źródło większości nieporozumień. Długość identyfikatorów w śladzie wybiera ten, kto wysłał pakiet jako pierwszy. Repeatery po drodze tylko się do niej dostosowują. Te z firmware 1.14 lub nowszym (wersja 1.14 wyszła w marcu 2026 roku) przekazują pakiety z identyfikatorami 1-, 2- i 3-bajtowymi i dopisują się w takiej długości, jaką wybrał nadawca. Starsze znają tylko jeden bajt, a pakiety z dłuższymi identyfikatorami są przez nie po cichu odrzucane.

Repeater: polecenie path.hash.mode

Polecenie path.hash.mode zmienia długość identyfikatora tylko w pakietach, które repeater sam wysyła. W praktyce chodzi głównie o jego ogłoszenia (advert). Nie zmienia on tego, co repeater przekazuje dalej, ani tego, jak dopisuje się do cudzych pakietów. Ustawia się je w konsoli repeatera poleceniem:

set path.hash.mode 1

Aby odczytać jakie jest obecne ustawienie należy użyć polecenia:

get path.hash.mode

Po co to ustawiać na repeaterze, skoro dotyczy to tylko advertów? Przydaje się to analizatorom i mapom, które rozpoznają wtedy repeater bez zgadywania. Dodatkowo cała okolica widzi, że repeater ma już firmware 1.14 lub nowszy, bo starszy nie zna tego polecenia. MeshMapper uznaje repeater za gotowy, gdy zobaczy jego ogłoszenie z dłuższym identyfikatorem albo zauważy, że przekazał pakiet z takim identyfikatorem, a właśnie od liczby gotowych repeaterów na danym obszarze zależy, kiedy można bezpiecznie przestawić companiony.

FAQ projektu Meshcore uważa, że ta zmiana nie ma niekorzystnych konsekwencji dla działania repeatera. Advert z dłuższym identyfikatorem nie przejdzie wprawdzie przez repeater starszy niż 1.14, ale to w końcu tylko ogłoszenie, a wiadomości użytkowników to ustawienie nie dotyczy. Niższy limit skoków też nie ma tu znaczenia, bo ogłoszenia repeaterów i tak domyślnie wędrują najwyżej 8 skoków (flood.max.advert).

Companion: ustawienie w aplikacji

W companionie długość śladu ścieżki ustawia się w aplikacji MeshCore, w menu Ustawienia → Ustawienia sieci. Potrzebny jest co najmniej firmware w wersji 1.14 oraz aplikacja w wersji 1.41.0 albo nowsze. Ten wybór obejmuje wszystko, co companion wysyła we flood: wiadomości na kanałach, pierwszą wiadomość do nowego kontaktu i szukanie trasy. I dopiero tu pojawiają się korzyści dla zwykłej rozmowy. Trasa do kontaktu zapisuje się dłuższymi identyfikatorami, więc wiadomość prywatną powtarza tylko właściwy repeater, a aplikacja pokazuje przy wiadomości repeatery, przez które naprawdę przeszła.

Jest tu mała pułapka. Companion pamięta trasy do kontaktów razem z długością identyfikatorów, więc po przełączeniu stare trasy zostają jednobajtowe, dopóki nie zostaną wyznaczone od nowa. Najprościej zresetować ścieżkę w ustawieniach kontaktu.

Dla dociekliwych: dłuższe identyfikatory dotyczą tylko repeaterów w śladzie. Adresat i nadawca wiadomości prywatnej są nadal oznaczani jednym bajtem klucza. Tam powtórka nie szkodzi, bo urządzenie i tak sprawdza, czy umie wiadomość odszyfrować.

Ile to kosztuje

Pole na ślad w pakiecie ma miejsce na 64 bajty, a dłuższe identyfikatory szybciej je zapełniają. Przy 1 bajcie limit pozycji w śladzie wiadomości to 64 skoków, przy 2 bajtach jest to już 32, a przy 3 bajtach - 21 . Gdy ślad się zapełni, kolejny repeater nie przekaże pakietu dalej. Krótko mówiąc - zwiększając rozmiar identyfikatora, skracamy maksymalną możliwą długość ścieżki pakietu.

Brzmi groźnie, ale w praktyce rzadko stanowi to problem. W dyskusji o domyślnych ustawieniach np. dla Kanady operatorzy dużych amerykańskich sieci pisali, że najdłuższe trasy, jakie widzieli, miały około 14–16 skoków. Liam Cottle, autor aplikacji MeshCore, ocenił, że 64 skoki są „zwykle nieosiągalne albo bardzo zawodne”. Niższy limit ma nawet zaletę: pakiety z odległych części sieci nie docierają tak daleko.

Drugi koszt to odrobinę dłuższe nadawanie. Przy ustawieniach EU/UK (Narrow), z których korzysta się w Polsce (SF8, szerokość kanału 62,5 kHz, CR 4/8), każdy dodatkowy bajt to średnio około 8 ms w eterze. Wiadomość na kanale, która przejdzie przez pięć repeaterów, zajmie eter łącznie o około 3% dłużej przy 2 bajtach i o około 7% dłużej przy 3 bajtach.

Najpoważniejszy koszt jedno, to zgodność. Jeśli na trasie stoi repeater z firmware starszym niż 1.14, wiadomość z dłuższymi identyfikatorami przepadnie bez żadnego komunikatu. Dlatego FAQ MeshCore radzi zostawić companiona na 1 bajcie, dopóki zdecydowana większość repeaterów w regionie nie przejdzie na 1.14 lub nowszy. W Polsce jednak repeatery z oprogramowaniem w wersji niższej niż 1.14 zdarzają się już bardzo rzadko.

Jak to wygląda w Polsce

Jak wspomniano w poprzednim akapicie, większość polskich repeaterów jest już zaktualizowana. MeshMapper publikuje tablicę, która pokazuje, ile repeaterów w każdym regionie obsługuje dłuższe identyfikatory. 25 października 2026 roku w 11 polskich regionach widział 2962 repeatery, z czego 2416 (81,6%) było gotowych. Średnia światowa wynosiła 85,8%. Te liczby są raczej zaniżone, bo repeater trafia do grupy gotowych dopiero wtedy, gdy MeshMapper zobaczy go w akcji.

Zmianę widać też w samym ruchu. Spośród 77 281 pakietów ze śladem, które analizator analyzer.marwoj.net zarejestrował między 22 a 25 października 2026 roku, 45% miało identyfikatory dwubajtowe, 16% trzybajtowe, a jednobajtowe już tylko 39%. Liczą się tu wszystkie rodzaje pakietów, także ogłoszenia repeaterów.

Region Południe, używający presetu z SF6, postawił sprawę jasno. Strona Prefix Meshcore Południe wymaga, żeby każdy repeater z firmware 1.14 lub nowszym w tym regionie miał ustawione set path.hash.mode 1, a użytkownikom podpowiada, gdzie w aplikacji przełączyć się na 2 bajty.

Niektóre kraje ustawiają to za użytkownika. W presetach radia, które aplikacja pobiera z serwera projektu, Czechy, Słowacja, Węgry, holenderska Limburgia i Nowa Zelandia mają wpisane 2 bajty, a Kanada i południowa Kalifornia 3 bajty. Preset EU/UK (Narrow), z którego korzysta się w Polsce, tego ustawienia nie zawiera, więc o długości decyduje, niestety, wybór w aplikacji. Cottle przy okazji kanadyjskiej zmiany napisał, że żadnemu nowemu presetowi nie poleciłby 1 bajtu jako ustawienia domyślnego.

Co ustawić

• Repeater z firmware 1.14 lub nowszym: wpisz set path.hash.mode 1. Niczego nie tracisz, a analizatory i sąsiedzi widzą, że repeater jest gotowy. W regionie Południe to obowiązek. Tryb 2 (3 bajty) jest dla ogłoszeń równie bezpieczny, ale Południe zaleca 2 bajty i lepiej trzymać się ustaleń w swoim regionie.
• Repeater ze starszym firmware: najpierw aktualizacja (pisaliśmy, jak zaktualizować repeater z telefonu). Stary repeater odrzuca pakiety z dłuższymi identyfikatorami i to on blokuje przejście okolicy na 2 bajty.
• Companion: przełącz się na 2 bajty, gdy zdecydowana większość repeaterów wokół ciebie ma firmware 1.14 lub nowszy. Sprawdź swój region na MeshMapper albo w analizatorze i zapytaj lokalną grupę. Po zmianie zresetuj ścieżki do kontaktów, z którymi piszesz najczęściej. Jeśli wiadomości przestaną dochodzić, wróć na 1 bajt i daj znać operatorom, bo na trasie stoi zapewne stary repeater.
• 3 bajty w companionie: w polskich sieciach na razie nie są konieczne. Przy dwóch bajtach powtórki zdarzają się rzadko, a żeby zaszkodziły trasie, oba repeatery musiałyby jeszcze słyszeć ten sam nadajnik. Trzy bajty to trochę dłuższe nadawanie i limit 21 skoków.

Po co to robić? Argumenty w pigułce

Na pytanie „co mi to da?” najkrótsza odpowiedź brzmi: sieć przestaje mylić repeatery. W szczegółach przejście z 1 na 2 albo 3 bajty oznacza, że:

• Wiadomości prywatne jadą właściwą drogą. Pakiet powtarza tylko ten repeater, który naprawdę jest na trasie. Jego przypadkowy „bliźniak” z tym samym identyfikatorem milczy.
• W eterze jest mniej zbędnego ruchu i zagłuszeń. Każda niepotrzebna transmisja zajmuje eter, który przydałby się innym, i zwiększa ryzyko, że dwa pakiety się nałożą.
• Widać prawdziwą trasę wiadomości. Aplikacja i analizatory pokazują repeatery, przez które wiadomość naprawdę przeszła, zamiast zgadywać.
• Łatwiej szukać usterek. Gdy coś nie dochodzi, od razu widać, który repeater zawiódł, zamiast sprawdzać kilka o tym samym identyfikatorze.
• Łatwiej planować i rozwijać sieć. Mapy połączeń i statystyki są wiarygodne, więc łatwiej ocenić, gdzie brakuje repeatera, gdzie jest ich za dużo i które łącza są naprawdę ważne.
• Pętle są wyłapywane szybciej. Repeater wcześniej rozpoznaje pakiet krążący w kółko i nie odrzuca przy tym zdrowych pakietów.
• Widać postęp aktualizacji. Repeater ogłaszający się dwoma bajtami pokazuje okolicy, że ma nowy firmware. Od tego zależy, kiedy wszyscy będą mogli przejść na dłuższe identyfikatory.
• Dalekie pakiety mają rozsądny limit. 32 skoki z zapasem wystarczają na najdłuższe trasy, a pakiet nie zawędruje dalej, niż trzeba.

Koszt jest niewielki: kilka procent dłuższego nadawania i niższy limit skoków. Pilnować trzeba jednego: żeby na trasie nie stał repeater starszy niż 1.14.

Artykuł powstał na podstawie dokumentacji i kodu źródłowego MeshCore 1.18.0, wpisu na blogu projektu o diagnostyce tras, dyskusji w zgłoszeniu #3302 na GitHubie, poradnika NodakMesh, presetów aplikacji MeshCore oraz danych MeshMapper i analizatora analyzer.marwoj.net.