Stabilna 4.17.1 i testowa 4.17.2

Najnowsza stabilna wersja to 4.17.1 z 23 października 2026 roku. Kolejna, 4.17.2, powstaje jako seria wersji testowych (RC, release candidate – kandydat do wydania). Opisujemy trzy z nich: rc5 z 29 października oraz rc6 i rc7 z 31 października. Twórcy zastrzegają, że wersji testowych nie należy uruchamiać w instalacji, od której zależy działanie sieci.

Pulpit pobiera 98% mniej danych

Głównym celem rc5 była wydajność. Aplikacja, a zwłaszcza jej część działająca w przeglądarce, była powolna, głównie przez ilość przesyłanych danych. Pulpit pobierał dane o węzłach przy każdym wejściu dwa razy, bez kompresji, po około 35 MB. Teraz pobiera je raz, skompresowane, i jest to około 0,23 MB. Pomija przy tym 37 pól, których nie wyświetla, oraz węzły, które mapa i tak by ukryła, bo dawno się nie odzywały. Kod zakładek ładuje się dopiero przy ich otwarciu, więc pierwsze otwarcie zakładki trwa 15–75 ms dłużej. Odpytywanie serwera w tle przesyła tylko zmiany od poprzedniego zapytania.

Obie wersje zmierzono jedna po drugiej na tym samym serwerze i tej samej bazie: 8 źródeł, około 930 węzłów Meshtastic i 300 MeshCore. „Telefon” oznacza w pomiarach mały ekran i procesor spowolniony czterokrotnie.

Pomiar rc4 rc5
Pulpit, pierwsze otwarcie strony 75,3 MB 1,56 MB
Dane węzłów dla pulpitu 2 × 35,6 MB 1 × 0,23 MB
Bezczynna karta, dane na minutę 1867 KB 12,9 KB
Odpowiedź serwera dla pulpitu (mediana) 611 ms 209 ms
Pierwszy znacznik na mapie, komputer / telefon 3,7 / 4,8 s 1,0 / 2,2 s
Wykresy w zakładce Info, komputer / telefon 1,9 / 6,2 s 0,7 / 2,0 s

W przeliczeniu karta z panelem otwarta przez godzinę w tle pobierała dotąd około 110 MB, a teraz niecały 1 MB. Różnicę odczuje każdy, kto zagląda do panelu z telefonu na danych komórkowych.

Poprawiono też płynność: wpisywanie wiadomości nie przerysowuje już całej aplikacji, a listy węzłów i kontaktów MeshCore dłuższe niż 100 pozycji rysują tylko wiersze widoczne na ekranie.

Automatyzacje telemetrii zaczną działać

W rc5 naprawiono wyzwalacz „telemetry received” (odebrano telemetrię). Dotąd nie uruchamiał się nigdy, a teraz działa dla źródeł Meshtastic podłączonych przez sieć (TCP) i przez MQTT. Ma przy tym dwa zabezpieczenia:

  • dany węzeł może uruchomić daną automatyzację najwyżej raz na godzinę, bez względu na przerwę ustawioną w automatyzacji;
  • odpowiedzi na prośby o telemetrię wysłane przez sam MeshMonitor są pomijane, więc automatyzacja, która o telemetrię prosi, nie uruchomi sama siebie. Ta reguła nie dotyczy odczytów lokalnego węzła, czyli radia podłączonego do MeshMonitora.

Przerwy między uruchomieniami i limity automatyzacji są teraz zapisywane w bazie danych, więc restart kontenera ani zapisanie automatyzacji ich nie zerują. Nowa wersja dodaje do bazy jedną tabelę; zmiana wykonuje się sama na SQLite, PostgreSQL i MySQL.

Przed aktualizacją trzeba przejrzeć automatyzacje z tym wyzwalaczem, zwłaszcza te, które wysyłają wiadomości. Dotąd nic nie robiły, a od rc5 zaczną działać. Przypomni o tym jednorazowy komunikat na stronie Automations. Limit godzinowy liczy się osobno dla każdego węzła, więc przy wielu węzłach jedna automatyzacja może w ciągu godziny wysłać sporo wiadomości. Każda z nich zajmuje czas nadawania, a ten w paśmie 868 MHz jest ograniczony przepisami.

Poprawki bezpieczeństwa w rc6

Wersja rc6 nie dodaje funkcji, tylko łata luki. Twórcy poddali kopię prawdziwej instalacji, z oczyszczoną bazą danych, automatycznemu testowi penetracyjnemu, czyli symulowanemu atakowi. Użyli narzędzia Shannon firmy Keygraph, które zgłasza problem dopiero wtedy, gdy potrafi go wykorzystać. Znalazło 38 problemów: 34 potwierdzono i naprawiono, 3 uznano za zamierzone działanie programu, a przy okazji poprawiono kilka kolejnych, które wyszły w trakcie prac.

Trzy zgłoszenia oznaczono jako krytyczne. Dwa dotyczyły silnika skryptów: użytkownik z prawem zmiany ustawień mógł przez niego uruchomić na serwerze dowolny kod. Trzecie pozwalało obejść ochronę przed fałszywymi żądaniami, które inna strona wysyła w imieniu zalogowanego użytkownika (CSRF). Najważniejsze poprawki w skrócie:

  • skryptami zarządza i uruchamia je tylko administrator, a skrypt nie dostaje tajnych danych serwera, takich jak hasła;
  • nazwa węzła odebrana z eteru nie przemyci już dodatkowych argumentów do skryptu uruchamianego przez automatyzację;
  • kopie zapasowe można pobierać i usuwać tylko z ich katalogu, a pełnych kluczy szyfrowania kanałów nie dostają użytkownicy z prawem tylko do odczytu;
  • warstwy mapy (GeoJSON) i ustawienia analityki nie wstrzykną już złośliwego skryptu do przeglądarki;
  • uprawnienia są sprawdzane dla źródła, którego dotyczy operacja;
  • zmiana hasła wylogowuje pozostałe sesje.

Szczegóły ataków są w niepublicznym biuletynie. Stabilna wersja 4.17.1 tych poprawek nie zawiera. Twórcy przypominają przy okazji, żeby zmienić domyślne hasło administratora (admin / changeme), trzymać MeshMonitor za logowaniem i nie wystawiać go do otwartego internetu.

Po aktualizacji konta bez uprawnień administratora mogą mniej: kopie zapasowe całego systemu wymagają administratora, eksport pełnego klucza kanału wymaga prawa zapisu, a ustawienia globalne zmienia tylko administrator. Połączenie z radiem MeshCore przez TCP nie przyjmuje już adresu 127.0.0.1, trzeba podać adres urządzenia w sieci lokalnej. Kto ma włączoną analitykę odwiedzin, powinien sprawdzić, czy jej skrypt dalej się ładuje, bo zmieniła się polityka bezpieczeństwa treści (CSP).

Mniej fałszywych alarmów i zmiany w MeshCore

Wersja rc7 zbiera dziesięć poprawek. Węzły z firmware Meshtastic 2.8 potrafią ponownie wysłać zapisaną bazę węzłów ze starymi odczytami. MeshMonitor brał je dotąd za świeże: zgłaszał restart węzła albo zmianę zasilania, a nawet uznawał, że węzeł jest prawdopodobnie na pokładzie samolotu. Teraz powtórzone dane są pomijane, więc powiadomienia i automatyzacje nie reagują na nieaktualne informacje.

W MeshCore pobieranie telemetrii według harmonogramu radzi sobie z utraconym pakietem. Na połączeniu przez kilka repeaterów jeden zgubiony pakiet oznaczał dotąd brak danych aż do następnego terminu. Teraz MeshMonitor ponawia prośbę co 90 s, najwyżej pięć razy, a potem robi 30 minut przerwy. Te wartości można zmienić osobno dla każdego źródła, a tę samą zasadę dostał harmonogram Meshtastic. Ponowienia mieszczą się w dotychczasowym limicie zapytań dla źródła.

Poza tym z MeshMonitora można usunąć wszystkie węzły MeshCore spoza ulubionych (lista kontaktów w samym radiu zostaje bez zmian), a własne reakcje w kanałach wyświetlają się jako ikonki zamiast surowego tekstu.

Jak sprawdzić wersję testową

Obrazy Docker wersji testowych są gotowe dla procesorów x86 (amd64) i ARM (arm64, armv7). Na instancji testowej wystarczy zmienić w pliku docker-compose.yml tag obrazu, na przykład na rc7:

image: ghcr.io/yeraze/meshmonitor:4.17.2-rc7

Potem pobrać nowy obraz i uruchomić kontener ponownie:

docker compose pull
docker compose up -d

Przed zmianą zrób kopię zapasową bazy, bo nowa wersja zmienia jej strukturę. Błędy twórcy proszą zgłaszać na GitHubie. Pełne opisy zmian są na stronach wydań rc5, rc6 i rc7.

Czym jest MeshMonitor

MeshMonitor to darmowa aplikacja o otwartym kodzie (licencja BSD-3-Clause), która zbiera w jednym panelu w przeglądarce to, co dzieje się w sieci mesh. Pokazuje węzły na mapie, wiadomości z kanałów, trasy pakietów i telemetrię, czyli odczyty wysyłane przez węzły, na przykład napięcie baterii. Obsługuje Meshtastic i MeshCore, a także brokery MQTT – serwery, do których bramki przesyłają pakiety odebrane z eteru.

To nie jest usługa w chmurze. Program instaluje się na własnym komputerze lub serwerze, najczęściej jako kontener Docker, czyli gotową paczkę z programem i wszystkim, czego potrzebuje. Są też wersje na Windows i macOS. Radio Meshtastic łączy się z MeshMonitorem przez sieć, USB albo Bluetooth, a radio MeshCore przez USB lub sieć. Takich źródeł może być kilka naraz, a każde konto użytkownika dostaje dostęp tylko do wybranych. Panel nada się więc zarówno dla kogoś z jednym węzłem w domu, jak i dla grupy, która utrzymuje sieć w regionie.

MeshMonitor potrafi też działać sam: odpowiada na wiadomości, wysyła zaplanowane komunikaty, reaguje, gdy węzeł wjedzie w wyznaczony obszar, uruchamia własne skrypty w Pythonie lub Bashu i wysyła powiadomienia na telefon. O raporcie zasięgu z wersji 4.16.2 pisaliśmy w tekście „MeshMonitor 4.16.2: pasywna mapa zasięgu Meshtastic i MeshCore”.

Artykuł powstał na podstawie not wydań MeshMonitor 4.17.1 i 4.17.2-rc5–rc7, wpisu na blogu projektu, zgłoszeń bezpieczeństwa w repozytorium Yeraze/meshmonitor oraz README projektu.