Levandor

Camera Stall Recovery (ONVIF reboot + clock) & Casino DNS Alerter

6 min read

Two follow-up items from the same day as the 2026-08-03-telep-router-factory-reset-recovery: (1) recovering the ÉSZAK/.139 dual-lens camera after its go2rtc RTSP streams wedged during the router rebuild — via an ONVIF camera reboot + a camwall restart, plus fixing the clock drift a reboot causes on the now-isolated camera; and (2) deploying the alert half of the casino/gambling detector on the rebuilt telep-router (Telegram alerts only — DNS blocking deliberately deferred).

For Agents

Camera map: .119 DÉL/South (healthy) serves Frigate telep_cam1 + telep_cam2; .139 ÉSZAK/North (the dual-lens that wedged) serves telep_cam3 + telep_cam4. Both are Tapo cams on the isolated cams WiFi (192.168.30.0/24), reached from telep-mainframe’s Frigate/go2rtc. Recovery scripts on the mainframe: /home/levander/tapo-ctl/reboot-onvif.py, /home/levander/tapo-ctl/set-cam-time.py. Casino alerter on the router (root@100.69.112.32): /etc/casino-alert.sh + procd service /etc/init.d/casino-alert (enabled). Blocking (/etc/casino-block.conf) is staged but NOT active. Secrets (WiFi keys, Telegram bot token) are kept OUT of this vault.

1. Camera stall — wedged RTSP after the router rebuild

Symptoms

  • After the router rebuild + isolating the cams (removing the cams → wan forwarding), the ÉSZAK/.139 dual-lens camera’s two Frigate cameras (telep_cam3, telep_cam4) dropped to ~0.7 fps (frozen on the TV camwall).
  • telep_cam1 / telep_cam2 (.119 DÉL) stayed healthy at ~5 fps throughout.

Root cause (NOT the internet isolation)

  • Re-adding cams → wan did not fix it — it made the streams 0 fps. So internet isolation was a red herring.
  • A fresh direct ffprobe against .139 worked fine (h264 720p) → the camera itself was serving RTSP.
  • The real cause: go2rtc’s existing streams were wedged. The dnsmasq / firewall restarts during the casino-block attempts dropped the camera’s weak WiFi link mid-stream and stuck its RTSP session slots. Tapo cams allow only a few concurrent RTSP connections and stale ones don’t close — so go2rtc couldn’t re-establish.
  • A full Frigate restart did NOT recover it (the stuck sessions live camera-side, not in Frigate/go2rtc).

Fix — reboot the camera over ONVIF

  • Reboot .139 via ONVIF: 
    ONVIFCamera(host, 2020, 'nvr42vhy1', pw).create_devicemgmt_service().SystemReboot()
  • pytapo can NOT do this — pytapo’s reboot needs TP-Link cloud creds, but the nvr42vhy1 account on these cams is ONVIF/RTSP-only (no cloud). ONVIF SystemReboot is the working path.
  • After ~90 s the camera came back and telep_cam3 / telep_cam4 recovered to 5.4 fps.
  • But the camwall (mpv on the TV) still showed those panes frozen — mpv holds the last frame of a stalled RTSP and won’t auto-reconnect. Fix: systemctl restart camwall.service to relaunch the mpv panes against the now-healthy streams.

Script: /home/levander/tapo-ctl/reboot-onvif.py.

Side effect — clock drift on the isolated camera

  • Rebooting .139 reset its clock (OSD showed 2026-04-21), and because the camera is isolated (no internet) it can’t NTP-sync.
  • Fix: push the correct time over ONVIF SetSystemDateAndTime:
    • DateTimeType = Manual
    • TimeZone = 'CET-1CEST,M3.5.0,M10.5.0/3'
    • UTCDateTime = <now>
  • Added a daily mainframe cron 30 4 * * * running /home/levander/tapo-ctl/set-cam-time.py to keep the isolated camera’s clock correct without giving it internet.

Script: /home/levander/tapo-ctl/set-cam-time.py.

Lessons

Recovering a wedged Tapo RTSP stream

go2rtc and mpv do NOT auto-recover a wedged RTSP session — a Frigate restart won’t clear it either, because the stuck session slots live camera-side. The recovery is a camera reboot (ONVIF SystemReboot) + a camwall.service restart, not a server-side restart.

Same fps=0 symptom, DIFFERENT root cause — branch on ip addr show br-cams

This incident is camera-side (RTSP session wedged, cameras still pingable). A later 2026-08-15 outage produced an identical fps=0 / frozen-camwall symptom but was router-side: a wifi reload left the wireless-only bridge br-cams state DOWN so the whole cams VLAN gateway/DHCP vanished and the cameras were L3-unreachable. Discriminator: if the cameras don’t ping (even from the router), it’s the bridge — fix with ifdown/ip link up/ifup cams, NOT an ONVIF reboot (which will ConnectTimeout on port 2020). See 2026-08-15-camwall-dead-br-cams-bridge-down-after-wifi-reload.

Rebooting an isolated Tapo camera loses its clock

An isolated camera (no internet) can’t NTP-sync, so every reboot leaves its clock wrong (OSD timestamp jumps back). Keep a periodic ONVIF SetSystemDateAndTime cron to re-sync the clock without exposing the camera to the internet.

pytapo vs ONVIF on these cams

The nvr42vhy1 account is ONVIF/RTSP-only — pytapo operations that need TP-Link cloud (like reboot) fail. Use the ONVIF device-management service (SystemReboot, SetSystemDateAndTime) on port 2020 instead.

2. Casino/gambling detector — alert half deployed (blocking deferred)

Deployed the alert half only on the rebuilt router. Blocking is staged but not active (see below).

Alerter (deployed, verified)

  • On the router (root@100.69.112.32): /etc/casino-alert.sh — a busybox-ash watcher.
  • It runs tail -F /tmp/dnsmasq-queries.log | while read line, matching a gambling keyword regex inside the while loop (casino|gambl|poker|bet365|1xbet|unibet|tippmix|stake.com|.casino|.poker|.bet|.bingo|...).

    • busybox grep has NO --line-buffered A piped tail -F … | grep --line-buffered … does not work under busybox — grep has no --line-buffered and buffers, so alerts never fire in real time. Match inside the while read line loop instead of via a piped grep.

  • Extracts the domain + client IP, applies a 1 h per-(client|domain) cooldown via /tmp/casino-alert-state, and sends a Telegram alert via uclient-fetch to the frigate-notify bot (chat_id -1004475187307; the token is read from /home/levander/nvr/frigate-notify/config.yml — kept OUT of this vault).
  • Runs as a procd service /etc/init.d/casino-alert (respawn, enabled).
  • Verified end-to-end: an injected test line fired the alert and Telegram returned ok:true.

Blocking (staged, NOT deployed)

  • The dnsmasq address= blocklist (/etc/casino-block.conf, gTLD wildcards .casino / .poker / .bingo / .bet + ~75 curated brand domains, included via conf-file in /etc/dnsmasq.conf) passed dnsmasq --test but dnsmasq did not answer the blocked query after restart.
  • The deploy script auto-rolled it back safely. Its verify now tests a LOCAL blocked query (not an upstream fetch like github) to avoid a false rollback on a WAN-lease flap.
  • Also: every dnsmasq restart risks re-stalling the weak .139 camera (this is exactly how the camera wedged in item 1).
  • TODO: debug blocking, ideally via addnhosts + SIGHUP (no dnsmasq restart) or during a maintenance window.

Restarting dnsmasq is doubly risky here

Beyond the DNS-outage risk from 2026-08-03-telep-router-factory-reset-recovery, each dnsmasq restart also drops the weak .139 camera’s WiFi mid-stream and wedges its RTSP slots (item 1). Prefer a no-restart apply path (addnhosts + SIGHUP) for the blocklist.

Graph View

Backlinks