Teltonika RUTX50 – Auto-Reset

Reading time 3 minutes

Der Teltonika RUTX50 hat zwei integrierte Funktionen für einen Auto-Reset, die allerdings nicht immer greifen: Wenn z.B. die LAN-Leds der LAN-Anschlüsse aktiv sind, aber weder GUI des Routers erreichbar, noch Netzwerkverkehr möglich ist, dann hilft nur ein Trennen der Spannungsversorgung, um den Router wieder in den Normalbetrieb zu bringen.

Dies zu automatisieren wird nachfolgend beschrieben.

Watchdog, Ping-Reboot und Hard-Recovery

Deshalb muss, neben integriertem Watchdog und Ping-Reboot eine dritte Sicherungsebene hinzugefügt werden.

Ebene	Auslöser	Recovery
1. Hardware-Watchdog	CPU/Kernel bedient Watchdog nicht mehr	Qualcomm-SoC-Reset nach ca. 30 s
2. Teltonika Ping-Reboot	Internet-Ping wiederholt erfolglos	Normaler RutOS-Software-Reboot
3. Hard-Recovery-Fallback	Lokale und externe Ziele dauerhaft unerreichbar	Watchdog-Feed stoppen → Hardware-Reset

1. Hardware-Watchdog prüfen

ps w | grep -E 'watchdog|procd'
ls -l /dev/watchdog*
dmesg | grep -Ei 'watchdog|wdt|reset|reboot|panic'
ubus call system watchdog

Bestätigter Zustand: procd and watchdogd laufen, /dev/watchdog and /dev/watchdog0 sind vorhanden. RutOS meldet status=running, timeout=30, frequency=5 and magicclose=false.

2. Hardware-Treiber identifizieren

ls -la /sys/class/watchdog/
readlink -f /sys/class/watchdog/watchdog0/device/driver

Der verwendete Treiber ist qcom_wdt, der Qualcomm-Hardware-Watchdog des SoC.

3. Teltonika Ping-Reboot prüfen

uci show | grep -i ping_reboot

Verwendete Konfiguration: Ziel 8.8.8.8, Intervall 5 Minuten, retry=2, Timeout 5 Sekunden, action=1. Im Teltonika-Skript wurde bestätigt, dass action=1 einen normalen Router-Reboot über rpc-sys/ubus auslöst.

4. Lokale Gegenstelle prüfen

ping -c 3 -W 2 192.168.1.1

Die lokale Gegenstelle des eingehenden Intenet-signals mit z.B. der IP 192.168.1.1 war stabil erreichbar. Sie hilft, einen reinen Internet-Ausfall von einem umfassenderen Netzwerk-/Router-Hänger zu unterscheiden.

5. Hardware-Reset kontrolliert verifizieren

ubus call system watchdog '{"stop":true}'

Der RUTX50 startete nach diesem kontrollierten Test selbstständig neu. Damit wurde praktisch bestätigt, dass das Stoppen des Watchdog-Feeds auf diesem Gerät einen echten Qualcomm-Hardware-Reset auslöst. Nach dem Neustart war der Watchdog automatisch wieder aktiv.

6. Hard-Recovery-Skript anlegen

mkdir -p /etc/scripts
cat > /etc/scripts/rutx50_hard_recovery.sh <<'EOF'
#!/bin/sh

STATEFILE="/tmp/rutx50_hard_recovery.fail"
LOCKFILE="/etc/rutx50_hard_recovery.lock"
LIMIT=4

LOCAL_TARGET="192.168.1.1"
EXT_TARGET1="8.8.8.8"
EXT_TARGET2="1.1.1.1"

reachable() {
    ping -c 1 -W 2 "$1" >/dev/null 2>&1
}

if reachable "$LOCAL_TARGET" || \
   reachable "$EXT_TARGET1" || \
   reachable "$EXT_TARGET2"; then
    echo 0 > "$STATEFILE"

    if [ -f "$LOCKFILE" ]; then
        rm -f "$LOCKFILE"
        logger -t rutx50-hard-recovery "Connectivity restored - hard recovery rearmed"
    fi

    exit 0
fi

if [ -f "$LOCKFILE" ]; then
    exit 0
fi

COUNT=0

if [ -f "$STATEFILE" ]; then
    COUNT="$(cat "$STATEFILE" 2>/dev/null)"
fi

case "$COUNT" in
    ''|*[!0-9]*) COUNT=0 ;;
esac

COUNT=$((COUNT + 1))
echo "$COUNT" > "$STATEFILE"

logger -t rutx50-hard-recovery \
    "Complete network failure $COUNT/$LIMIT - local and external targets unreachable"

if [ "$COUNT" -ge "$LIMIT" ]; then
    logger -t rutx50-hard-recovery \
        "Persistent complete network failure - triggering Qualcomm hardware watchdog reset"

    touch "$LOCKFILE"
    sync
    ubus call system watchdog '{"stop":true}'
fi

exit 0
EOF

chmod 755 /etc/scripts/rutx50_hard_recovery.sh

Die Hard-Recovery eskaliert erst, wenn weder o.g. IP 192.168.1.1 noch 8.8.8.8 or 1.1.1.1 erreichbar sind. Bei LIMIT=4 und einem 5-Minuten-Intervall ergibt sich eine Eskalationszeit von ungefähr 20 Minuten. Das Lockfile verhindert eine unmittelbare Reset-Schleife.

7. Skript im gesunden Zustand testen

/etc/scripts/rutx50_hard_recovery.sh
echo $?
cat /tmp/rutx50_hard_recovery.fail

Bestätigtes Testergebnis: Exit-Code 0, Fail-Counter 0, kein Reset.

8. Cron-Job aktivieren

echo '*/5 * * * * /etc/scripts/rutx50_hard_recovery.sh' > /etc/crontabs/root
/etc/init.d/cron restart
cat /etc/crontabs/root

Der eigene Job läuft getrennt von Teltonikas /etc/crontabs/preboot. Der Teltonika-Eintrag bleibt unverändert:

*/5 * * * * /usr/sbin/ping_reboot.sh cfg01c21d

9. Parallele Ausführung kontrollieren

logread | grep -E 'ping_reboot|rutx50-hard-recovery|crond' | tail -30

Im Log wurden sowohl der Teltonika-Job unter USER preboot als auch das eigene Skript unter USER root gestartet.

10. Persistenz nach Neustart prüfen

ls -l /etc/scripts/rutx50_hard_recovery.sh
cat /etc/crontabs/root
ubus call system watchdog

Nach dem Neustart waren Skript und Cron-Eintrag weiterhin vorhanden. Der Watchdog meldete erneut status=running, timeout=30, frequency=5 and magicclose=false.

Endzustand

Der RUTX50 besitzt jetzt drei sich ergänzende Recovery-Ebenen: Qualcomm-Hardware-Watchdog, Teltonika Ping-Reboot und den separaten Hard-Recovery-Fallback. Das originale Teltonika-Skript wurde nicht verändert.

Das absichtliche Stoppen des Watchdog-Feeds löst auf dem konkret getesteten RUTX50 einen Neustart aus. Einen solchen Test nur durchführen, wenn physischer Zugriff auf das Gerät besteht.

Hard-Recovery auch nach RutOS-Firmware-Updates erhalten

Nach der Einrichtung der zusätzlichen Hard-Recovery wurde geprüft, ob die dafür notwendigen Dateien bei einem RutOS-Firmware-Update mit beibehaltenen Einstellungen automatisch gesichert werden.

1. Prüfen, welche Dateien bereits durch sysupgrade gesichert werden

sysupgrade -l | grep -E 'rutx50_hard_recovery|crontabs/root|ping_reboot'

Im Ausgangszustand wurden bereits folgende Dateien in der Upgrade-Sicherung geführt:

/etc/config/ping_reboot
/etc/config/siteman_ping_reboot
/etc/crontabs/root

Damit waren sowohl die Teltonika-Ping-Reboot-Konfiguration als auch der eigene Root-Cronjob bereits Bestandteil des sysupgrade-Backups. Das eigentliche zusätzliche Recovery-Skript fehlte jedoch noch:

/etc/scripts/rutx50_hard_recovery.sh

2. sysupgrade-Konfiguration prüfen

cat /etc/sysupgrade.conf

Die Datei enthielt nur die Standardkommentare:

## This file contains files and directories that should
## be preserved during an upgrade.
# /etc/example.conf
# /etc/openvpn/

3. Hard-Recovery-Skript ausdrücklich zur Upgrade-Sicherung hinzufügen

echo '/etc/scripts/rutx50_hard_recovery.sh' >> /etc/sysupgrade.conf

Anschließend kontrollieren:

cat /etc/sysupgrade.conf

Am Ende muss nun stehen:

/etc/scripts/rutx50_hard_recovery.sh

4. Abschließend kontrollieren, ob RutOS das Skript wirklich übernimmt

sysupgrade -l | grep -E 'rutx50_hard_recovery|crontabs/root|ping_reboot'

Der abschließende Test ergab:

/etc/config/ping_reboot
/etc/config/siteman_ping_reboot
/etc/crontabs/root
/etc/scripts/rutx50_hard_recovery.sh

Damit werden jetzt alle für die eingerichtete Recovery relevanten Bestandteile bei einem normalen RutOS-Firmware-Upgrade mit beibehaltener Konfiguration gesichert und wiederhergestellt.

Bestandteil	Pfad	Upgrade-Persistenz
Teltonika Ping-Reboot	/etc/config/ping_reboot	Ja
Siteman Ping-Reboot	/etc/config/siteman_ping_reboot	Ja
Hard-Recovery Cronjob	/etc/crontabs/root	Ja
Hard-Recovery Skript	/etc/scripts/rutx50_hard_recovery.sh	Ja, nach Eintrag in /etc/sysupgrade.conf

Diese Absicherung gilt für normale Firmware-Upgrades, bei denen die bestehende Konfiguration übernommen wird.
Bei Factory Reset, bewusstem Löschen der Einstellungen oder einem Upgrade ohne Übernahme der Konfiguration müssen die eigenen Anpassungen erneut eingerichtet werden.

Endzustand der gesamten Absicherung

1. Qualcomm Hardware-Watchdog
   → echter CPU-/Kernel-Hänger
   → Hardware-Reset nach ca. 30 Sekunden

2. Teltonika Ping-Reboot
   → wiederholter Internet-Ausfall
   → normaler RutOS-Software-Reboot

3. Eigener Hard-Recovery-Fallback
   → lokale und externe Ziele über mehrere Zyklen unerreichbar
   → Watchdog-Feed wird gestoppt
   → Qualcomm-Hardware-Reset

4. Firmware-Update-Persistenz
   → Ping-Reboot, Cronjob und Hard-Recovery-Skript
   → Bestandteil des sysupgrade-Backups