{"id":13605,"date":"2026-08-21T09:59:41","date_gmt":"2026-08-21T09:59:41","guid":{"rendered":"https:\/\/csiag.eu\/?p=13605"},"modified":"2026-08-21T18:00:02","modified_gmt":"2026-08-21T18:00:02","slug":"teltonika-rutx50-auto-reset","status":"publish","type":"post","link":"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/","title":{"rendered":"Teltonika RUTX50 &#8211; Auto-Reset"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of contents<\/p>\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#Watchdog_Ping-Reboot_und_Hard-Recovery\" >Watchdog, Ping-Reboot und Hard-Recovery<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#1_Hardware-Watchdog_prufen\" >1. Hardware-Watchdog pr\u00fcfen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#2_Hardware-Treiber_identifizieren\" >2. Hardware-Treiber identifizieren<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#3_Teltonika_Ping-Reboot_prufen\" >3. Teltonika Ping-Reboot pr\u00fcfen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#4_Lokale_Gegenstelle_prufen\" >4. Lokale Gegenstelle pr\u00fcfen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#5_Hardware-Reset_kontrolliert_verifizieren\" >5. Hardware-Reset kontrolliert verifizieren<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#6_Hard-Recovery-Skript_anlegen\" >6. Hard-Recovery-Skript anlegen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#7_Skript_im_gesunden_Zustand_testen\" >7. Skript im gesunden Zustand testen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#8_Cron-Job_aktivieren\" >8. Cron-Job aktivieren<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#9_Parallele_Ausfuhrung_kontrollieren\" >9. Parallele Ausf\u00fchrung kontrollieren<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#10_Persistenz_nach_Neustart_prufen\" >10. Persistenz nach Neustart pr\u00fcfen<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#Endzustand\" >Endzustand<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#Hard-Recovery_auch_nach_RutOS-Firmware-Updates_erhalten\" >Hard-Recovery auch nach RutOS-Firmware-Updates erhalten<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#1_Prufen_welche_Dateien_bereits_durch_sysupgrade_gesichert_werden\" >1. Pr\u00fcfen, welche Dateien bereits durch sysupgrade gesichert werden<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#2_sysupgrade-Konfiguration_prufen\" >2. sysupgrade-Konfiguration pr\u00fcfen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#3_Hard-Recovery-Skript_ausdrucklich_zur_Upgrade-Sicherung_hinzufugen\" >3. Hard-Recovery-Skript ausdr\u00fccklich zur Upgrade-Sicherung hinzuf\u00fcgen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#4_Abschliesend_kontrollieren_ob_RutOS_das_Skript_wirklich_ubernimmt\" >4. Abschlie\u00dfend kontrollieren, ob RutOS das Skript wirklich \u00fcbernimmt<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/#Endzustand_der_gesamten_Absicherung\" >Endzustand der gesamten Absicherung<\/a><\/li><\/ul><\/nav><\/div>\n<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading time<\/span> <span class=\"rt-time\"> 3<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span>\n<p class=\"wp-block-paragraph\">Der Teltonika RUTX50 hat zwei integrierte Funktionen f\u00fcr einen Auto-Reset, die allerdings nicht immer greifen: Wenn z.B. die LAN-Leds der LAN-Anschl\u00fcsse aktiv sind, aber weder GUI des Routers erreichbar, noch Netzwerkverkehr m\u00f6glich ist, dann hilft nur ein Trennen der Spannungsversorgung, um den Router wieder in den Normalbetrieb zu bringen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dies zu automatisieren wird nachfolgend beschrieben.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Watchdog_Ping-Reboot_und_Hard-Recovery\"><\/span>Watchdog, Ping-Reboot und Hard-Recovery<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Deshalb muss, neben integriertem Watchdog und Ping-Reboot eine dritte Sicherungsebene hinzugef\u00fcgt werden.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Ebene<\/th><th>Ausl\u00f6ser<\/th><th>Recovery<\/th><\/tr><\/thead><tbody><tr><td>1. Hardware-Watchdog<\/td><td>CPU\/Kernel bedient Watchdog nicht mehr<\/td><td>Qualcomm-SoC-Reset nach ca. 30 s<\/td><\/tr><tr><td>2. Teltonika Ping-Reboot<\/td><td>Internet-Ping wiederholt erfolglos<\/td><td>Normaler RutOS-Software-Reboot<\/td><\/tr><tr><td>3. Hard-Recovery-Fallback<\/td><td>Lokale und externe Ziele dauerhaft unerreichbar<\/td><td>Watchdog-Feed stoppen \u2192 Hardware-Reset<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"1_Hardware-Watchdog_prufen\"><\/span>1. Hardware-Watchdog pr\u00fcfen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ps w | grep -E 'watchdog|procd'\nls -l \/dev\/watchdog*\ndmesg | grep -Ei 'watchdog|wdt|reset|reboot|panic'\nubus call system watchdog<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Best\u00e4tigter Zustand: <code>procd<\/code> and <code>watchdogd<\/code> laufen, <code>\/dev\/watchdog<\/code> and <code>\/dev\/watchdog0<\/code> sind vorhanden. RutOS meldet <code>status=running<\/code>, <code>timeout=30<\/code>, <code>frequency=5<\/code> and <code>magicclose=false<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"2_Hardware-Treiber_identifizieren\"><\/span>2. Hardware-Treiber identifizieren<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -la \/sys\/class\/watchdog\/\nreadlink -f \/sys\/class\/watchdog\/watchdog0\/device\/driver<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der verwendete Treiber ist <code>qcom_wdt<\/code>, der Qualcomm-Hardware-Watchdog des SoC.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"3_Teltonika_Ping-Reboot_prufen\"><\/span>3. Teltonika Ping-Reboot pr\u00fcfen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>uci show | grep -i ping_reboot<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verwendete Konfiguration: Ziel <code>8.8.8.8<\/code>, Intervall 5 Minuten, <code>retry=2<\/code>, Timeout 5 Sekunden, <code>action=1<\/code>. Im Teltonika-Skript wurde best\u00e4tigt, dass <code>action=1<\/code> einen normalen Router-Reboot \u00fcber <code>rpc-sys\/ubus<\/code> ausl\u00f6st.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"4_Lokale_Gegenstelle_prufen\"><\/span>4. Lokale Gegenstelle pr\u00fcfen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ping -c 3 -W 2 192.168.1.1<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die lokale Gegenstelle des eingehenden Intenet-signals mit z.B. der IP <code>192.168.1.1<\/code> war stabil erreichbar. Sie hilft, einen reinen Internet-Ausfall von einem umfassenderen Netzwerk-\/Router-H\u00e4nger zu unterscheiden.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"5_Hardware-Reset_kontrolliert_verifizieren\"><\/span>5. Hardware-Reset kontrolliert verifizieren<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ubus call system watchdog '{\"stop\":true}'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der RUTX50 startete nach diesem kontrollierten Test selbstst\u00e4ndig neu. Damit wurde praktisch best\u00e4tigt, dass das Stoppen des Watchdog-Feeds auf diesem Ger\u00e4t einen echten Qualcomm-Hardware-Reset ausl\u00f6st. Nach dem Neustart war der Watchdog automatisch wieder aktiv.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"6_Hard-Recovery-Skript_anlegen\"><\/span>6. Hard-Recovery-Skript anlegen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir -p \/etc\/scripts\ncat &gt; \/etc\/scripts\/rutx50_hard_recovery.sh &lt;&lt;'EOF'\n#!\/bin\/sh\n\nSTATEFILE=\"\/tmp\/rutx50_hard_recovery.fail\"\nLOCKFILE=\"\/etc\/rutx50_hard_recovery.lock\"\nLIMIT=4\n\nLOCAL_TARGET=\"192.168.1.1\"\nEXT_TARGET1=\"8.8.8.8\"\nEXT_TARGET2=\"1.1.1.1\"\n\nreachable() {\n    ping -c 1 -W 2 \"$1\" &gt;\/dev\/null 2&gt;&amp;1\n}\n\nif reachable \"$LOCAL_TARGET\" || \\\n   reachable \"$EXT_TARGET1\" || \\\n   reachable \"$EXT_TARGET2\"; then\n    echo 0 &gt; \"$STATEFILE\"\n\n    if &#91; -f \"$LOCKFILE\" ]; then\n        rm -f \"$LOCKFILE\"\n        logger -t rutx50-hard-recovery \"Connectivity restored - hard recovery rearmed\"\n    fi\n\n    exit 0\nfi\n\nif &#91; -f \"$LOCKFILE\" ]; then\n    exit 0\nfi\n\nCOUNT=0\n\nif &#91; -f \"$STATEFILE\" ]; then\n    COUNT=\"$(cat \"$STATEFILE\" 2&gt;\/dev\/null)\"\nfi\n\ncase \"$COUNT\" in\n    ''|*&#91;!0-9]*) COUNT=0 ;;\nesac\n\nCOUNT=$((COUNT + 1))\necho \"$COUNT\" &gt; \"$STATEFILE\"\n\nlogger -t rutx50-hard-recovery \\\n    \"Complete network failure $COUNT\/$LIMIT - local and external targets unreachable\"\n\nif &#91; \"$COUNT\" -ge \"$LIMIT\" ]; then\n    logger -t rutx50-hard-recovery \\\n        \"Persistent complete network failure - triggering Qualcomm hardware watchdog reset\"\n\n    touch \"$LOCKFILE\"\n    sync\n    ubus call system watchdog '{\"stop\":true}'\nfi\n\nexit 0\nEOF\n\nchmod 755 \/etc\/scripts\/rutx50_hard_recovery.sh<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Hard-Recovery eskaliert erst, wenn weder o.g. IP <code>192.168.1.1<\/code> noch <code>8.8.8.8<\/code> or <code>1.1.1.1<\/code> erreichbar sind. Bei <code>LIMIT=4<\/code> und einem 5-Minuten-Intervall ergibt sich eine Eskalationszeit von ungef\u00e4hr 20 Minuten. Das Lockfile verhindert eine unmittelbare Reset-Schleife.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"7_Skript_im_gesunden_Zustand_testen\"><\/span>7. Skript im gesunden Zustand testen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/scripts\/rutx50_hard_recovery.sh\necho $?\ncat \/tmp\/rutx50_hard_recovery.fail<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Best\u00e4tigtes Testergebnis: Exit-Code <code>0<\/code>, Fail-Counter <code>0<\/code>, kein Reset.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"8_Cron-Job_aktivieren\"><\/span>8. Cron-Job aktivieren<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>echo '*\/5 * * * * \/etc\/scripts\/rutx50_hard_recovery.sh' &gt; \/etc\/crontabs\/root\n\/etc\/init.d\/cron restart\ncat \/etc\/crontabs\/root<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der eigene Job l\u00e4uft getrennt von Teltonikas <code>\/etc\/crontabs\/preboot<\/code>. Der Teltonika-Eintrag bleibt unver\u00e4ndert:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>*\/5 * * * * \/usr\/sbin\/ping_reboot.sh cfg01c21d<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"9_Parallele_Ausfuhrung_kontrollieren\"><\/span>9. Parallele Ausf\u00fchrung kontrollieren<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>logread | grep -E 'ping_reboot|rutx50-hard-recovery|crond' | tail -30<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Im Log wurden sowohl der Teltonika-Job unter <code>USER preboot<\/code> als auch das eigene Skript unter <code>USER root<\/code> gestartet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"10_Persistenz_nach_Neustart_prufen\"><\/span>10. Persistenz nach Neustart pr\u00fcfen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -l \/etc\/scripts\/rutx50_hard_recovery.sh\ncat \/etc\/crontabs\/root\nubus call system watchdog<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nach dem Neustart waren Skript und Cron-Eintrag weiterhin vorhanden. Der Watchdog meldete erneut <code>status=running<\/code>, <code>timeout=30<\/code>, <code>frequency=5<\/code> and <code>magicclose=false<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Endzustand\"><\/span>Endzustand<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der RUTX50 besitzt jetzt drei sich erg\u00e4nzende Recovery-Ebenen: Qualcomm-Hardware-Watchdog, Teltonika Ping-Reboot und den separaten Hard-Recovery-Fallback. Das originale Teltonika-Skript wurde nicht ver\u00e4ndert.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Das absichtliche Stoppen des Watchdog-Feeds l\u00f6st auf dem konkret getesteten RUTX50 einen Neustart aus. Einen solchen Test nur durchf\u00fchren, wenn physischer Zugriff auf das Ger\u00e4t besteht.<\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:100px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hard-Recovery_auch_nach_RutOS-Firmware-Updates_erhalten\"><\/span>Hard-Recovery auch nach RutOS-Firmware-Updates erhalten<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Nach der Einrichtung der zus\u00e4tzlichen Hard-Recovery wurde gepr\u00fcft, ob die daf\u00fcr notwendigen Dateien bei einem RutOS-Firmware-Update mit beibehaltenen Einstellungen automatisch gesichert werden.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"1_Prufen_welche_Dateien_bereits_durch_sysupgrade_gesichert_werden\"><\/span>1. Pr\u00fcfen, welche Dateien bereits durch sysupgrade gesichert werden<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>sysupgrade -l | grep -E 'rutx50_hard_recovery|crontabs\/root|ping_reboot'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Im Ausgangszustand wurden bereits folgende Dateien in der Upgrade-Sicherung gef\u00fchrt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/config\/ping_reboot\n\/etc\/config\/siteman_ping_reboot\n\/etc\/crontabs\/root<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Damit waren sowohl die Teltonika-Ping-Reboot-Konfiguration als auch der eigene Root-Cronjob bereits Bestandteil des sysupgrade-Backups. Das eigentliche zus\u00e4tzliche Recovery-Skript fehlte jedoch noch:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/scripts\/rutx50_hard_recovery.sh<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"2_sysupgrade-Konfiguration_prufen\"><\/span>2. sysupgrade-Konfiguration pr\u00fcfen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/sysupgrade.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Datei enthielt nur die Standardkommentare:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>## This file contains files and directories that should\n## be preserved during an upgrade.\n# \/etc\/example.conf\n# \/etc\/openvpn\/<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"3_Hard-Recovery-Skript_ausdrucklich_zur_Upgrade-Sicherung_hinzufugen\"><\/span>3. Hard-Recovery-Skript ausdr\u00fccklich zur Upgrade-Sicherung hinzuf\u00fcgen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>echo '\/etc\/scripts\/rutx50_hard_recovery.sh' &gt;&gt; \/etc\/sysupgrade.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Anschlie\u00dfend kontrollieren:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/sysupgrade.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Am Ende muss nun stehen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/scripts\/rutx50_hard_recovery.sh<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"4_Abschliesend_kontrollieren_ob_RutOS_das_Skript_wirklich_ubernimmt\"><\/span>4. Abschlie\u00dfend kontrollieren, ob RutOS das Skript wirklich \u00fcbernimmt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>sysupgrade -l | grep -E 'rutx50_hard_recovery|crontabs\/root|ping_reboot'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der abschlie\u00dfende Test ergab:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/config\/ping_reboot\n\/etc\/config\/siteman_ping_reboot\n\/etc\/crontabs\/root\n\/etc\/scripts\/rutx50_hard_recovery.sh<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Damit werden jetzt alle f\u00fcr die eingerichtete Recovery relevanten Bestandteile bei einem normalen RutOS-Firmware-Upgrade mit beibehaltener Konfiguration gesichert und wiederhergestellt.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Bestandteil<\/th><th>Pfad<\/th><th>Upgrade-Persistenz<\/th><\/tr><\/thead><tbody><tr><td>Teltonika Ping-Reboot<\/td><td><code>\/etc\/config\/ping_reboot<\/code><\/td><td>Ja<\/td><\/tr><tr><td>Siteman Ping-Reboot<\/td><td><code>\/etc\/config\/siteman_ping_reboot<\/code><\/td><td>Ja<\/td><\/tr><tr><td>Hard-Recovery Cronjob<\/td><td><code>\/etc\/crontabs\/root<\/code><\/td><td>Ja<\/td><\/tr><tr><td>Hard-Recovery Skript<\/td><td><code>\/etc\/scripts\/rutx50_hard_recovery.sh<\/code><\/td><td>Ja, nach Eintrag in <code>\/etc\/sysupgrade.conf<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Diese Absicherung gilt f\u00fcr normale Firmware-Upgrades, bei denen die bestehende Konfiguration \u00fcbernommen wird.<br>Bei Factory Reset, bewusstem L\u00f6schen der Einstellungen oder einem Upgrade ohne \u00dcbernahme der Konfiguration m\u00fcssen die eigenen Anpassungen erneut eingerichtet werden.<\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:100px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Endzustand_der_gesamten_Absicherung\"><\/span>Endzustand der gesamten Absicherung<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>1. Qualcomm Hardware-Watchdog\n   \u2192 echter CPU-\/Kernel-H\u00e4nger\n   \u2192 Hardware-Reset nach ca. 30 Sekunden\n\n2. Teltonika Ping-Reboot\n   \u2192 wiederholter Internet-Ausfall\n   \u2192 normaler RutOS-Software-Reboot\n\n3. Eigener Hard-Recovery-Fallback\n   \u2192 lokale und externe Ziele \u00fcber mehrere Zyklen unerreichbar\n   \u2192 Watchdog-Feed wird gestoppt\n   \u2192 Qualcomm-Hardware-Reset\n\n4. Firmware-Update-Persistenz\n   \u2192 Ping-Reboot, Cronjob und Hard-Recovery-Skript\n   \u2192 Bestandteil des sysupgrade-Backups<\/code><\/pre>","protected":false},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading time<\/span> <span class=\"rt-time\"> 3<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span>Der Teltonika RUTX50 hat zwei integrierte Funktionen f\u00fcr einen Auto-Reset, die allerdings nicht immer greifen: Wenn z.B. die LAN-Leds der LAN-Anschl\u00fcsse aktiv sind, aber weder GUI des Routers erreichbar, noch Netzwerkverkehr m\u00f6glich ist, dann hilft nur ein Trennen der Spannungsversorgung, um den Router wieder in den Normalbetrieb zu bringen. Dies zu automatisieren wird nachfolgend beschrieben.&hellip;&nbsp;<a href=\"https:\/\/csiag.eu\/en\/blog\/2026\/08\/21\/teltonika-rutx50-auto-reset\/\" rel=\"bookmark\">Read More \"<span class=\"screen-reader-text\">Teltonika RUTX50 &#8211; Auto-Reset<\/span><\/a><\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[2868],"tags":[],"class_list":["post-13605","post","type-post","status-publish","format-standard","hentry","category-router"],"modified_by":"Achim Goerner","_links":{"self":[{"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/posts\/13605","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/comments?post=13605"}],"version-history":[{"count":9,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/posts\/13605\/revisions"}],"predecessor-version":[{"id":13618,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/posts\/13605\/revisions\/13618"}],"wp:attachment":[{"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/media?parent=13605"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/categories?post=13605"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/csiag.eu\/en\/wp-json\/wp\/v2\/tags?post=13605"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}