During Wi-Fi tuning on telep-router (2026-08-30→31), a wifi reload raced the cams interface as it claimed its bridge br-cams, leaving cams stuck in netifd state DEVICE_CLAIM_FAILED ("up": false). The cameras stayed Wi-Fi-associated but were L3-unreachable, so Frigate lost all 4 feeds and camwall.service hung in activating (start-pre). The per-minute /etc/cams-guard.sh could NOT recover it — ifup cams cannot clear a DEVICE_CLAIM_FAILED claim. Only a full /etc/init.d/network restart brought it back.
wifi reload can race the cams L3 interface into DEVICE_CLAIM_FAILED — and ifup cams will NOT clear it
Tuning Wi-Fi on telep1 (setting multicast_to_unicast, then dtim_period/uapsd), each change followed by wifi reload, bounced the cams AP phy1-ap1 (SSID telep-cc). Because phy1-ap1 is the only member of br-cams, the reload raced the cams interface as it re-claimed the bridge. netifd left cams at "up": false with errors: ["DEVICE_CLAIM_FAILED"]. The 192.168.30.1/24 L3 assignment was gone → cameras L3-unreachable, Frigate feeds dead, camwall wedged. This is a distinct failure from the 2026-08-15 outage — see the branch table below; the 08-15 fix (ifup cams down/up cycle) does NOT work here.
For Agents
Two DIFFERENT wifi reload failure modes on the cams VLAN — branch on the netifd state, the fix differs:
br-cams device present/up but ifstatus cams = "up": false + errors: ["DEVICE_CLAIM_FAILED"] → THIS incident (L3 claim stuck). ifup cams does NOT clear it. Fix = /etc/init.d/network restart.
Camera map:cams VLAN = 192.168.30.0/24, gateway/DHCP 192.168.30.1 on br-cams (only member = phy1-ap1 = SSID telep-cc). Tapo cams: .119 “Kamera DÉL” = telep_cam1+telep_cam2; .139 “telep_cam2”/ÉSZAK = telep_cam3+telep_cam4. Router ssh root@100.69.112.32; mainframe 192.168.1.123 / ssh levander@100.115.209.87.
Trigger
Iterative Wi-Fi tuning on the telep1 SSIDs, each uci commit followed by a wifi reload:
# multicast_to_unicast on both telep1 ifaces, then a later pass:uci set wireless.<iface>.dtim_period=...uci set wireless.<iface>.uapsd=...uci commit wirelesswifi reload # <-- bounces phy1-ap1 (cams AP) each time
Every wifi reload bounces the cams AP phy1-ap1. Since it is the sole member of br-cams, one of these reloads raced the cams interface mid-claim and wedged it.
Symptom chain
ifstatus cams → "up": false, errors: ["DEVICE_CLAIM_FAILED"]. The br-camsdevice stays present/up; only the L3 interface (the 192.168.30.1 assignment) failed.
Tapo cameras .119/.139 (and telep_cam1/3/4) show as Wi-Fi ASSOCIATED — stations present on phy1-ap1 — but are L3-UNREACHABLE from both the router and the mainframe (192.168.1.123).
Because the box can’t reach the cameras, Frigate lost all 4 feeds (telep_cam1–4).
camwall.service hung in activating (start-pre) — its ExecStartPre loops until curl -sf http://127.0.0.1:5000/api/version (Frigate’s API), which never returns while feeds are dead. So “cams unavailable” and “camwall stuck” both trace back to the same cams gateway being down.
camwall stuck in start-pre is a downstream symptom, not the fault
camwall.service gates on Frigate (ExecStartPre = until curl -sf http://127.0.0.1:5000/api/version). When the cams VLAN is down Frigate has no feeds, so camwall correctly waits forever. Do NOT debug camwall — fix the cams gateway on the router first, and camwall proceeds to active on its own.
Root cause
wifi reload races the cams interface as it claims br-cams (a bridge whose only member is a Wi-Fi AP). netifd leaves cams at "up": false with errors: [DEVICE_CLAIM_FAILED]. The bridge device br-cams itself stays up/present — only the L3 interface (the 192.168.30.1 assignment) fails to attach.
Why the existing cams-guard did NOT save it
The router runs /etc/cams-guard.sh every minute (cron). It detects “br-cams down (no 192.168.30.1)” and runs ifup cams. But ifup cams cannot clear a DEVICE_CLAIM_FAILED state — it retried every minute for ~5 min with zero effect. The guard was written for the carrier-down case, not the stuck-claim case.
/etc/init.d/network restart # full netifd restart — clears the stuck claimifstatus cams | grep '"up"' # now: "up": trueip -4 addr show br-cams # now: inet 192.168.30.1/24
Result: cams came back "up": true with 192.168.30.1/24, both cameras reachable, camwall went active, Frigate got all 4 feeds back (telep_cam1–4, ~5fps).
Only a FULL network restart cleared it — the lighter fixes did NOT
These all failed to clear DEVICE_CLAIM_FAILED:
ifup cams (what cams-guard runs)
ip link set br-cams down; /etc/init.d/network reload; ifup cams
Only /etc/init.d/network restart (a full netifd restart) worked.
/etc/cams-guard.sh is being hardened to escalate to /etc/init.d/network restart after 3 consecutive failed ifup cams attempts, so it can self-heal from the DEVICE_CLAIM_FAILED state without manual intervention.
Operational rule going forward
After ANY wifi reload / wireless commit on telep-router, VERIFY the cams VLAN
ifstatus cams | grep '"up"' # must be trueip -4 addr show br-cams # must show inet 192.168.30.1/24
If either fails → /etc/init.d/network restart. (Not ifup cams, not network reload — those don’t clear a stuck claim.)