Vzrok izpada RMS najden v sistemskem dnevniku — ni težava z napajanjem ali signalom
Analiza sistemskega dnevnika (syslog) je razkrila točen vzrok izpada RMS.
Glavni vzrok: sesutje mosquitto (MQTT) — SIGSEGV v libssl.so.3
Dne 30. 3. ob 19:52:15 je odjemalec RMS MQTT izgubil povezavo in se ni mogel ponovno povezati:
- Koda: Izberi vse
rms_mqtt[5147]: Mosquitto disconnected: The connection was lost.
rms_mqtt[5147]: Connection timeout (60), retrying
rms_mqtt[5147]: Mosquitto reconnecting
rms_mqtt[5147]: Mosquitto disconnected: The connection was refused.
To se je ponavljalo ~3 minute, nato je ob 19:55:25 prišlo do trdega sesutja:
- Koda: Izberi vse
kernel: do_page_fault(): sending SIGSEGV to mosquitto loop for invalid write access to 7782d35c
kernel: epc = 7797c6a8 in libssl.so.3[77967000+87000]
kernel: ra = 7797c640 in libssl.so.3[77967000+87000]
Segmentation fault v libssl.so.3 znotraj mosquitto TLS zanke — knjižnica SSL/TLS je sesla z neveljavnim pisanjem v pomnilnik. To je v celoti ubilo proces rms_mqtt.
Naprava se je samodejno obnovila — ob 20:25:53 se je nov proces rms_mqtt (PID 8701, namesto sesutega 5147) registriral in ponovno povezal:
- Koda: Izberi vse
rms_mqtt[8701]: Registering device
rms_mqtt[8701]: Mosquitto connected
Skupno trajanje izpada RMS: 19:52 → 20:25 = ~33 minut
Dodatna ugotovitev: vzrok izpada 28. 3.
Sistemski dnevnik se začne šele pri sob 28. 3. ob 21:21 — to je prva vrstica. Predhodni izpad od 00:14 do 07:58 preprosto ni v dnevniku, ker je bil dnevnik ob ponovnem zagonu pobrisan/rotiran. V kombinaciji s padcem temperature naprave na 28°C (iz 39°C) to potrjuje, da se je naprava znova zagnala okoli 00:14 in se dnevnik začel znova po vzpostavitvi ob 07:58.
Opazna vzorec: avtomatske prijave v WebUI
Vsakih 5 minut, neprekinjeno, 24/7 z naslova 192.168.1.152 (gostiteljem: morje — RPi5):
- Koda: Izberi vse
vuci: accepted login for admin from 192.168.1.152
To je verjetno Rpanion-server ali kakšna druga skripta za nadzor na RPi5, ki vsakih 5 minut anketira WebUI usmerjevalnika RUT241. To povzroča znatno obremenitev sej. Vredno omembe — sčasoma lahko prispeva k pritisku na pomnilnik, kar je morda povezano s poškodbo pomnilnika v libssl (fragmentacija kopice pri dolgotrajni obremenitvi).
Povzetek:
- Koda: Izberi vse
Dogodek Čas Vzrok
28. 3. izpad 7,7h 00:14 - 07:58 Ponovni zagon naprave (dnevnik pobrisan, potrditev s padcem temp.)
30. 3. izpad RMS ~33 min 19:52 - 20:25 mosquitto SIGSEGV sesutje v libssl.so.3
Ponastavitve modemskih Večkrat Obnove gostovalnih sej, normalno
števcev
Priporočeni ukrepi:
- Takoj: posodobitev firmware — sesutje libssl je skoraj zagotovo znana napaka, odpravljena v novejši različici RUT2M. Preverite trenutno verzijo in najnovejšo na firmware.teltonika-networks.com
- Razmislite: Prijave v WebUI vsakih 5 minut z RPi5 — če gre za nadzorno skripto, jo zamenjajte z neposrednimi klici prek RMS API ali ubus/SSH, ki so bistveno lažji za pomnilnik kot seje WebUI
Ali šibek LTE signal povzroča težave z RMS in stabilnostjo povezave?
Kratki odgovor: da — posredno, a pomembno.
Izmerjene vrednosti signala (3-dnevno povprečje):
- Koda: Izberi vse
Meritev Povprečje Dobro Mejno Slabo
RSRP -86 dBm > -80 -80 do -90 < -90
RSRQ -10 dB > -10 -10 do -15 < -15
SINR +10 dB > +13 +3 do +13 < +3
Signal je na meji med sprejemljivim in mejnim. V kombinaciji z gostovanjem to povzroča nestabilnost.
Neposredni učinki šibkega signala:
- Višja izguba paketov in retransmisije → TCP seje se zagozdijo ali prekinejo
- Modem dvigne TX moč za kompenzacijo → večja poraba toka → napetostne konice na napajanju
- Pogostejši preklopi med celicami — v dnevniku zaznane 4 različne cell ID (10392075, 10392085, 10392095, 10392105) → kratke prekinitve pri vsakem prehodu
Posredni učinki na RMS:
- MQTT teče prek TLS — izguba paketov med TLS rokovanjem povzroči "connection refused" (točno to je bilo zabeleženo v dnevniku)
- Ponovni poskusi povezave povzročajo pritisk na pomnilnik → v kombinaciji z napako v libssl je to verjetno sprožilo sesutje SIGSEGV
Faktor gostovanja:
Naprava je ves čas na TM HR (T-Mobile Hrvaška) v gostovanju. To pomeni:
- Hrvaško omrežje nima obveznosti prioritizirati vaše SIM kartice
- Gostovalne seje imajo krajše PDP context timeoutte → operater prekine sejo → modem se mora znova registrirati (vidno kot 4x ponastavitev prometnih števcev v dnevniku)
Priporočene rešitve:
- Zunanja antena: RUT241 ima dva SMA priključka za LTE diversity. Usmerjena panelna LTE antena lahko prinese 10–15 dB izboljšave — razlika med RSRP −86 in −72 je popolnoma drugačen razred zanesljivosti
- Preverite konektorje: Rahel SMA konektor ali poškodovan koaksialni kabel lahko povzroči 5–10 dB izgube
- Zaklepanje frekvenčnega pasu: Preverite prek SSH kateri pas uporablja modem:
- Koda: Izberi vse
gsmctl -A 'AT+QCFG="band"'
- SIM kartica: Razmislite o lokalni hrvaški SIM ali multi-IMSI IoT SIM z boljšimi gostovalnimi sporazumi za napravo trajno nameščeno na Hrvaškem
Zaključek:
Šibek signal ni neposredno povzročil sesutja mosquitta (to je napaka firmware/libssl), je pa prispeval k ponastavitvam modema in prekinjenjem gostovalnih sej ter ustvarja okolje, v katerem se programske napake pogosteje pojavijo.
Prioriteta ukrepov: 1. posodobitev firmware → 2. izboljšava antene
