Full survey of telep-router — the Asus RT-AX89X running OpenWrt 24.10.0 that serves the Telephely site LAN. Covers hardware, firmware, network/firewall config, WiFi, Tailscale, and the known footguns to be aware of before making changes.
For Agents
Access:/usr/bin/ssh root@telep-router (reachable over Tailscale MagicDNS, no port-forward needed).
Config system: OpenWrt UCI — change via uci set ... + uci commit <pkg> + reload the relevant init script. Never hand-edit /etc/config/* if a UCI path exists.
Blast radius: this is the only gateway for the site LAN. A bad network or firewall commit locks you out of everything except the physical console.
Before inbound/port-forward work, read Double-NAT — the router does not hold a public IP.
Hardware & Firmware
Property
Value
Device
Asus RT-AX89X
Target
qualcommax/ipq807x
Arch
aarch64_cortex-a53
Firmware
OpenWrt 24.10.0
Build
r28427-6df0e3d02a
Kernel
6.6.73
Resources
Comfortable headroom — this router is nowhere near its limits.
Resource
Total
Used / Free
RAM
887 MB
~594 MB available
Overlay (/dev/ubi0_5)
206 MB
20 MB used (10%)
/rom
—
100% full
/rom at 100% is normal
/rom is the read-only squashfs base image. It is supposed to report full — it is not a disk-space problem and needs no action. The number that actually matters is the overlay, and that is at 10%. There is plenty of room to install packages.
br-lan = 192.168.1.1/24 — the gateway address for the site.
Bridge members: lan1–lan8, 10g-sfp, 10g-copper, and both WiFi APs.
Only 10g-copper currently has a link. Every other physical port is idle.
WAN
DHCP client, leased 192.168.254.2/24 from upstream gateway 192.168.254.1 — the TP-Link NE200 CPE.
The upstream NE200 is a 5G NR cellular FWA CPE, NOT a WISP point-to-point radio
The WAN uplink is a TP-Link NE200 5G NR cellular fixed-wireless-access (FWA) CPE with a SIM on Telekom Hungary (Telekom HU NET) — a mobile-network link, not a line-of-sight WISP bridge. It connects over NR5G (LTE anchors B3 1800 MHz ×2 CA + B8 900 MHz, plus 5G N78 3.5 GHz) and hands this router a CGNAT address, which is why the Double-NAT exists. Uplink quality is governed by cellular RF metrics (RSRP/RSRQ/SINR) and by the carrier data-cap / fair-use policy on the SIM — see RF baseline captured 2026-08-31 — root cause confirmed for the confirmed weak-signal baseline.
Double-NAT
The router sits behind another router
The WAN address (192.168.254.2) is an RFC1918 private address, not a public one. Traffic is NATed twice: once by telep-router (masquerade), once by the upstream box at 192.168.254.1.
Consequences:
A port-forward configured here is not reachable from the internet — it also needs a matching forward on the upstream router (which we may not control).
Anything that needs inbound reachability should go over Tailscale instead of port-forwarding. That is the path of least resistance and already works today.
Protocols that dislike double-NAT (some VoIP/SIP, strict-NAT gaming, UPnP/NAT-PMP chains) may misbehave.
DHCP (dnsmasq)
Setting
Value
Pool start
.100
Limit
150 addresses
Lease time
12h
Domain
lan
Static reservations of note: telep-mainframe.123 (d8:5e:d3:a7:05:d6), the two Tapo cams on the cams VLAN (.119/.139), and the TL-WA850RE wired AP .101 (ac:84:c6:1b:04:30, added 2026-08-15 — see [[#tp-link-tl-wa850re-added-as-a-wired-ap-ssid-bandi|TP-Link TL-WA850RE added as a wired AP (SSID bandi)]]).
Firewall
Zone
Input
Output
Forward
Notes
lan
ACCEPT
ACCEPT
ACCEPT
wan
REJECT
ACCEPT
REJECT
masq=1, mtu_fix=1
cams
—
—
—
isolated camera VLAN, see
Forwardings: lan → wan and lan → cams. There is deliberately no cams → wan rule. One DNAT rule (NTP), added for the cameras.
Camera VLAN (telep-cc)
Added 2026-07-14 to isolate the site’s IP cameras from everything else. Consumed by telep-mainframe, which pulls RTSP from it.
Property
Value
Subnet
192.168.30.0/24
SSID
hidden, WPA2-PSK
Client isolation
on
Occupant
Tapo TC47 @ 192.168.30.119
Rules:
cams → wan REJECTED — the cameras have no internet at all. No cloud, no phone-home, no firmware calling out.
lan → cams ALLOWED — this is the only path in, and it is how Frigate reaches RTSP.
NTP is DNAT’d back to the router, so a camera with no internet still keeps its clock.
WPA2, not WPA3 — and that is forced
The camera VLAN runs WPA2-PSK because Tapo hardware does not support WPA3-SAE. The isolation (no internet, no lateral path, hidden SSID, client isolation) is what carries the security here, not the WiFi crypto.
The Tapo app can no longer reach the camera
Consequence of the above: no cloud path, and a phone on the LAN is a different subnet with client isolation on. Changing a camera setting now requires temporarily reopening the VLAN. See Camera network.
Hidden-SSID rejoin was tested — the camera was deauthed and re-associated cleanly, keeping its lease.
WiFi
Radio
Band
Channel
Mode
TX power
radio0
5 GHz
36
HE40 (was HE80, narrowed 2026-08-15)
23 dBm (ETSI ceiling)
radio1
2.4 GHz
1
HE20
20 dBm (ETSI ceiling)
SSID telep1 on the 5 GHz radio (radio0 / phy0-ap0, ch36); 2.4 GHz is a separate SSID telep1-2G (radio1 / phy1-ap0, ch11) — see the split in telep-mainframe-handover §3d. Guest cams SSID telep-cc is phy1-ap1 (isolated, br-cams).
Encryption: WPA3-SAE (encryption='sae').
WiFi range / wall penetration — TX power is maxed, width is the lever
Both radios are already at the HU/ETSI regulatory TX-power ceiling (5 GHz 23 dBm, 2.4 GHz 20 dBm — the UI “max” is real), so power is not adjustable. On 2026-08-15 radio0 was narrowed HE80 → HE40 (uci set wireless.radio0.htmode='HE40'; uci commit wireless; wifi reload) to concentrate the same power into half the bandwidth (≈ +3 dB range, peak 1200→600 Mbps; reversible). The bigger un-applied win is band steering (dawn package) to move far/through-wall clients onto 2.4 GHz. See 2026-08-15-router-wifi-tuning-htmode-band-penetration.
The PSK is only 8 characters
SAE’s dragonfly handshake means an attacker cannot capture a handshake and crack it offline — each guess costs an online interaction, so a short passphrase is far less catastrophic than it would be under WPA2. But 8 chars is still short, and it removes any margin if a downgrade/transition-mode path or a future SAE weakness ever appears. Worth lengthening when convenient.
Keep the 5 GHz radio on a NON-DFS channel or Macs won't see the SSID
If the 5 GHz SSID lands on a DFS channel (52–144) — e.g. after a reflash/reset re-picks the channel — macOS won’t list it in the Wi-Fi menu (passive-scan of DFS), while phones show it instantly. Set a non-DFS channel (36/40/44/48 or 149/153/157/161): iwinfo to find the 5 GHz radioX, then uci set wireless.radioX.channel='149'; uci commit wireless; wifi reload. Full runbook: 2026-08-26-router-reflash-mac-5ghz-dfs-and-bambu-offline. NB (2026-08-26 correction): the current 5 GHz channel is 36 — already non-DFS, so a later “Mac can’t reach the printer” turned out to be not DFS but driver-level cross-band isolation (see next callout).
Cross-band Wi-Fi client isolation is at the DRIVER level — config knobs won't disable it
A wireless client on telep1 (5 GHz) cannot reach a wireless client on telep1-2G (2.4 GHz) — e.g. the Mac can’t reach the Bambu printer 192.168.1.202. Every config layer reads non-isolating: hostapd ap_isolate is set only on telep-cc (phy1-ap1), NOT on phy0-ap0/phy1-ap0; uci wireless.*.isolate='0'; bridge ports isolated=0 learning=1 *_flood=1; br-lan vlan_filtering=0. A wifi down; wifi up changes nothing. Decisive tell: wifi→ethernet works (reaches wired .123/.200) but wifi→wifi cross-band fails → isolation is in the radio driver/firmware, below every knob. Fix: wire the printer via Ethernet (reachable from any band), or put the client on the same band. Tailscale does NOT help an on-LAN client (connected route wins). Full diagnosis: Problem 3 — Wi-Fi cross-band client isolation (driver-level).
⚠️ Do NOT conflate this with AirPlay.telep-tv not showing on Wi-Fi is a separate, band-independent bug: the switch doesn’t flood multicast arriving on the box’s 10G port (br-lan port 2, enp5s0 @ 10000 Mbps) out to Wi-Fi, while 1G-port devices (the printer) do reach Wi-Fi. Unicast is fine. See 2026-08-30-telep-tv-airplay-10g-port-multicast-not-flooded.
telep-tv AirPlay undiscoverable on Wi-Fi = 10G-port multicast NOT flooded (band-independent)
The box (telep-mainframe, 192.168.1.123, MAC d8:5e:d3:a7:05:d6) sits on br-lan port 2 = a 10G link (enp5s0 negotiated 10000 Mbps). Its mDNS _airplay._tcp/_raop._tcp multicast (224.0.0.251) is verified on the wire via tcpdump but never reaches Wi-Fi clients — while 1G-port devices (HP printer on port 5) DO reach Wi-Fi (Mac on port 11 = phy0-ap0). Bridge multicast_snooping=0 (floods), no flow_offloading, no packet_steering. Fails on BOTH 2.4 and 5 GHz ⇒ NOT the cross-band isolation above. Unicast unaffected (ssh/ping/dns-sd -L/AirPlay-connect all work), only dns-sd -B discovery fails. Quick fix: move the box cable to a 1G LAN port (loses 10G). Keep-10G fix: mDNS reflector re-advertising telep-tv at the box IP:port. Deeper: investigate the DSA switch’s multicast-to-CPU behavior on the 10G port. Full diagnosis: 2026-08-30-telep-tv-airplay-10g-port-multicast-not-flooded.
Printable scan-to-join QR sheet
To make a guest Wi-Fi QR code for telep1, read ssid/key here via uci show wireless and follow 2026-07-31-wifi-qr-code-sheet. Use a T:WPA payload — it joins this WPA3/SAE network fine.
Tailscale
Property
Value
Version
1.80.3
Init script
S80tailscale
Firewall mode
nftables
Port
41641
State file
/etc/tailscale/tailscaled.state
Tailnet IP
100.69.112.32 (telep-router) — changed from 100.115.194.51 after the 2026-08-03 factory reset (fresh node registration)
This is what makes the router reachable at all despite the Double-NAT — SSH to it via MagicDNS from any tailnet device.
Packages
174 installed — essentially stock. The only things added beyond the base image:
tailscale
luci-app-firewall
luci-app-package-manager
Notably absent (i.e. available as future improvements): adblock, SQM / QoS, DNS-over-HTTPS, wireguard.
Changes Made (2026-07-13)
Hostname was still OpenWrt
The name telep-router existed only as a Tailscale MagicDNS name. The device itself did not know it:
kernel hostname → OpenWrt
uname -n → OpenWrt
uci get system.@system[0].hostname → OpenWrt
Fixed so all three agree:
uci set system.@system[0].hostname='telep-router'uci commit system/etc/init.d/system reload
The shell prompt, syslog entries, and DHCP-advertised hostname now all say telep-router.
Changes Made (2026-07-28)
IPv6 disabled on the LAN (2026-07-28)
The router was advertising a global IPv6 prefix (2a00:1110:210:7653::/64) and a ULA (fd83:5e9d:98ca::/64) to LAN clients via RA/DHCPv6 — but IPv6 had no working upstream (fixed-wireless WAN + Double-NAT carries no v6). macOS prefers IPv6 (RFC 6724 / Happy Eyeballs), tried the dead v6 path first, and stalled 2–7 s per dual-stack site before falling back to IPv4 — the user’s Mac “slow internet”. Full diagnosis + signature: 2026-07-28-ipv6-slow-internet.
Fix — make the LAN IPv4-only and drop the WAN6 client:
uci set dhcp.lan.ra='disabled'uci set dhcp.lan.dhcpv6='disabled'uci set dhcp.lan.ndp='disabled'uci set network.wan6.disabled='1'uci commit/etc/init.d/odhcpd restart/etc/init.d/network reload
Reversible — restore the backups + reload to re-enable v6 if the upstream ever gains real IPv6.
Do not re-enable IPv6 on the LAN until the upstream actually carries it
The underlying problem is the Double-NAT5G NR cellular FWA WAN (TP-Link NE200, Telekom HU SIM), whose CGNAT path had no working IPv6 for the LAN. Re-advertising a v6 prefix over a v6-dead link brings the macOS stall straight back. Bridging/DMZ-ing the NE200 to remove the double-NAT is the separate fix that could restore genuine IPv6 (the NE200 itself does receive a routed public v6 /64 from the carrier).
Changes Made (2026-08-03)
Factory reset + rebuild after a casino-blocker DNS outage
The router was factory-reset on 2026-08-03 and rebuilt from scratch
A subagent deploying a casino/gambling DNS blocklist restarted dnsmasq with a broken config, then died mid-deploy → DNS down site-wide. No config backup existed, so the router was factory-reset and rebuilt over SSH via the telep-mainframe jump host. Full incident + rebuild steps: 2026-08-03-telep-router-factory-reset-recovery.
Key deltas from the reset (details in the incident note):
Tailnet IP changed 100.115.194.51 → 100.69.112.32 (fresh Tailscale node registration). MagicDNS telep-router / telep-router.taild4189d.ts.net unchanged. Update any root@100.115.194.51 references.
DNS query logging restored: logqueries=1, logfacility=/tmp/dnsmasq-queries.log, plus /etc/dns-log-rotate.sh (now truncates in place at 20 MB — no dnsmasq restart on rotate, unlike the old mv+restart version) on an hourly cron.
Camera network rebuilt as cams: static 192.168.30.1/24 on bridge br-cams, DHCP pool, reservations telep_cam1 (18:69:45:a9:01:25→.119) and telep_cam2 (c0:3a:55:5c:8b:33→.139). New cams firewall zone; forwardings cams → wan (cameras now have internet) and lan → cams. Note this reverses the old no-internet posture in Camera VLAN (telep-cc).
Mainframe SSH key (levander@telep-mainframe ed25519) added to the router’s authorized keys.
A config backup now exists — restore, don't rebuild
mainframe:/home/levander/telep-router-config-backup-20260803.tar.gz (13 KB, sysupgrade -b). Restore via LuCI → System → Backup/Flash Firmware → Restore. Make periodic backups.
Changes Made (2026-08-12)
AirPlay mDNS fix — patched out netifd’s ap_isolate auto-injection
The telep1 client BSSes were dropping wired→Wi-Fi mDNS multicast (AirPlay discovery of telep-tv) because the running hostapd conf had ap_isolate=1 on both bands — even though uci show wireless and ubus call network.wireless status reported isolate:false.
Root cause: /lib/netifd/netifd-wireless.sh → _wireless_set_brsnoop_isolation (line ~309) auto-injects isolate 1 into the generated hostapd config for any bridged, non-isolated AP when multicast_to_unicast is on. The value is promoted to the interface top-level as 1, so it fires transiently at config-generation time regardless of the uci isolate/multicast_to_unicast settings.
The uci isolate=0 recipe does NOT work — patch line 309 instead
Setting uci set wireless.telep1_{5,2}.isolate='0' + wifi reload (or wifi down; wifi up, or network reload) leaves /var/run/hostapd-phy*.confbyte-identical with ap_isolate=1. The only fix that took was disabling the injection line:
grep -n 'json_add_boolean isolate 1' /lib/netifd/netifd-wireless.sh # confirm the linecp /lib/netifd/netifd-wireless.sh /lib/netifd/netifd-wireless.sh.baksed -i '309s/^/#DISABLED-airplay-fix#/' /lib/netifd/netifd-wireless.shwifi down; wifi up
Result: telep1 (both bands) has no ap_isolate line (mDNS/AirPlay flows); telepcc / cams keeps ap_isolate=1 (its explicit isolate=1 early-returns before line 309, so camera isolation is preserved). Backup: /lib/netifd/netifd-wireless.sh.bak.
Reapply after every OpenWrt sysupgrade
This patches a /lib/netifd/ system file, so a sysupgrade reverts it and AirPlay breaks again. Re-grep for json_add_boolean isolate 1 (line numbers shift across versions), re-apply the sed, wifi down; wifi up.
Also committed alongside (harmless, intent-consistent, not sufficient alone): uci set wireless.telep1_5.isolate=0, telep1_2.isolate=0, telep1_5.multicast_to_unicast=0, telep1_2.multicast_to_unicast=0.
Added a dnsmasq wildcard address record so every *.telep.lan name resolves to the mainframe (192.168.1.123) for LAN clients — the local half of the internet-independent access path (Caddy reverse proxy is on telep-mainframe):
Site-wide DHCP+DNS outage from a duplicate dhcp-host (RESOLVED)
A duplicate dhcp-host IP makes dnsmasq refuse to start — DHCP AND DNS down site-wide
On 2026-08-15, adding a reservation for the AirPlay receiver created a second dhcp-host for 192.168.1.123 (section dhcp.telep_tv, same MAC d8:5e:d3:a7:05:d6 as the existing canonical dhcp.@host[2]telep-mainframe). dnsmasq treats this as fatal (duplicate dhcp-host IP address 192.168.1.123 … FAILED to start up) and does not start → no leases, no DNS, whole site offline ~8.5 h. Fix:
Before adding any dhcp-host:uci show dhcp | grep -iE '<ip>|<mac>'. The telep-mainframe reservation already owns .123/d8:5e:d3:a7:05:d6 — the AirPlay telep-tv receiver IS the mainframe, so do not add a separate reservation for it. Full post-mortem: 2026-08-15-dhcp-outage-duplicate-reservation-postmortem.
cams-VLAN outage — br-cams stuck DOWN after a wifi reload (RESOLVED)
A wifi reload can take the wireless-only cams bridge br-cams DOWN and it does NOT auto-recover
On 2026-08-15, a 2.4 GHz channel change during WiFi tuning (uci set wireless.radio1.channel=11; uci commit; wifi reload) bounced the cams AP phy1-ap1 (SSID telep-cc, network=cams). Because phy1-ap1 is the only member of br-cams, the bridge went carrier-down and OpenWrt left it in state DOWN, qdisc noop with no inet — the static network.cams config (192.168.30.1/24 on br-cams) was NOT reapplied. Cameras stayed WiFi-associated but were L3-unreachable → all 4 Frigate cams fps=0, camwall froze.
ifup cams alone does NOT fix it (nor /etc/init.d/network reload; wifi up). What worked was a forced down/up cycle:
ifdown cams; sleep 2; ip link set dev br-cams up; ifup cams; sleep 5ip addr show br-cams # now UP with inet 192.168.30.1/24
On 2026-08-31, Wi-Fi tuning on telep1 (multicast_to_unicast, then dtim_period/uapsd, each uci commit; wifi reload) raced the cams interface as it re-claimed br-cams and left it stuck: ifstatus cams = "up": false + errors: ["DEVICE_CLAIM_FAILED"]. Here the br-camsdevice stays up/present — only the L3 192.168.30.1/24 assignment failed. Same downstream symptoms (cameras associated but L3-unreachable, all 4 Frigate feeds dead, camwall.service hung in activating (start-pre) on its Frigate ExecStartPre gate).
ifup cams does NOT clear a DEVICE_CLAIM_FAILED claim (nor ip link set br-cams down; /etc/init.d/network reload; ifup cams). The per-minute /etc/cams-guard.sh — which only runs ifup cams — retried for ~5 min with no effect. Only a full /etc/init.d/network restart works:
/etc/init.d/network restartifstatus cams | grep '"up"' # now "up": trueip -4 addr show br-cams # now inet 192.168.30.1/24
Branch on state:br-camsstate DOWN qdisc noop → carrier-down (2026-08-15 fix above). ifstatus camsDEVICE_CLAIM_FAILED → this case (network restart). Full incident: 2026-08-31-cams-vlan-device-claim-failed-wifi-reload.
Verify after ANY wifi reload/wireless commit:ifstatus cams | grep '"up"' true AND ip -4 addr show br-cams shows 192.168.30.1; else /etc/init.d/network restart.
TP-Link TL-WA850RE added as a wired AP (SSID bandi)
A TP-Link TL-WA850RE (single-band 2.4 GHz N300 range-extender, no 5 GHz) was reconfigured from range-extender/repeater mode into Access Point mode and wired into a telep-router LAN port (bridged into br-lan). It broadcasts the SSID bandi — this resolves an earlier mystery: the bandi seen on 2.4 GHz ch2 in WiFi scans was this device, not an unknown neighbour AP.
Property
Value
Model
TP-Link TL-WA850RE (2.4 GHz N300, single-band)
Role
Access Point (was repeater — wireless backhaul was slow)
SSID
bandi (2.4 GHz)
WiFi BSSID
ac:84:c6:1b:04:31
Eth / mgmt MAC
ac:84:c6:1b:04:30
IP
192.168.1.101 (static DHCP reservation, see below)
wired into a br-lan LAN port, 100 Mb Fast Ethernet
It is a coverage AP, not a fast-lane AP — the 100 Mb link and 2.4 GHz N300 ceiling cap throughput. Use it to fill a dead zone, not for bandwidth.
DHCP reservation added on the router (dhcp.@host[3]):
uci show dhcp | grep -iE 'ac:84:c6:1b:04:30|192.168.1.101' # pre-check for duplicates FIRST# name=TL-WA850RE mac=ac:84:c6:1b:04:30 ip=192.168.1.101 dns=1/etc/init.d/dnsmasq restart # then VERIFY dnsmasq is actually running
Pre-check every reservation — the duplicate- dhcp-host outage lesson
This reservation was added with a uci show dhcp | grep <mac/ip> pre-check and dnsmasq was verified still running afterwards, per the duplicate-reservation outage — a duplicate dhcp-host IP makes dnsmasq refuse to start and takes DHCP+DNS down site-wide.
Reaching a TP-Link extender that is still in repeater mode
While in repeater mode the WA850RE had no router-assigned IP (transparent, default 192.168.0.254), so tplinkrepeater.net / the dashboard were unreachable from a 192.168.1.x client. Reach an extender in that state via the TP-Link Tether app, or give a laptop a temporary 192.168.0.x static IP and browse to http://192.168.0.254.
Confirm an AP is actually wired before trusting it
The first attempt “plugged into port 4” left the port at carrier=0 (no link) and the AP MAC never appeared on any wired port — the device was silently still on wireless backhaul. A different cable fixed the link, after which it pulled the DHCP lease. Diagnose from the router:
cat /sys/class/net/lanN/carrier # 1 = link up on that portbrctl showmacs br-lan | grep ac:84:c6:1b:04:30 # MAC learned on a wired port = truly wired
Gotchas
1. WiFi ifaces declare network='lan wan'
Both wifi-iface sections list network='lan wan', and network.wan carries type='bridge'.
Currently inert — the APs only ever land in br-lan, because wan is not actually instantiated as a bridge device. So nothing is broken today.
But it is a live footgun. It is one config change away from bridging the wireless APs directly onto the WAN side, which would put WiFi clients outside the firewall. Should be cleaned up to network='lan' on both ifaces.
2. 8-character WiFi PSK
See WiFi. SAE mitigates offline cracking; the passphrase is still short.
3. Double-NAT
See Double-NAT. Know this before attempting any port-forward or inbound work.
macOS: bare ssh is broken by a shell wrapper
On the Mac, a shell wrapper/alias shadows ssh and breaks the connection. Invoke the absolute path:
/usr/bin/ssh root@telep-router
This applies to any script or agent automating against the router from macOS.
Security Gaps
Known and unresolved as of 2026-07-14. None are actively exploited; all are worth closing.
Gap
Why it matters
8-char WPA3 PSK on telep1
See — SAE blunts offline cracking, but there is no margin left.
dropbear password auth enabled
SSH accepts passwords. Should be keys-only.
LuCI on plain HTTP (port 80)
The admin UI credentials cross the LAN in cleartext.
Plaintext DNS
All lookups are visible to the upstream network. DoH/DoT is available and unused.
OpenWrt 24.10.0 not patched
Not on the latest point release.
Open Items
Guard the wireless-only br-cams bridge against wifi reload — a hotplug hook to auto ifup cams after wifi events, or add a persistent dummy member so br-cams never goes carrier-down. See Durable guards (NOT yet applied — user to decide). In progress:/etc/cams-guard.sh being hardened to escalate to /etc/init.d/network restart after 3 consecutive failed ifup cams — needed because ifup cams cannot clear the DEVICE_CLAIM_FAILED variant (see 2026-08-31-cams-vlan-device-claim-failed-wifi-reload).
Clean up network='lan wan' → network='lan' on both wifi-iface sections.
Lengthen the WiFi PSK beyond 8 characters.
Close the Security Gaps: dropbear keys-only, LuCI behind HTTPS, DoH, patch to the latest 24.10.x.
Consider adblock / DoH / SQM — plenty of overlay space (10% used) and RAM (594 MB free) to support them.
Reapply the AirPlay netifd patch after any sysupgrade — see [[#airplay-mdns-fix—patched-out-netifds-ap_isolate-auto-injection|AirPlay mDNS fix — patched out netifd’s ap_isolate auto-injection]]; a firmware upgrade reverts /lib/netifd/netifd-wireless.sh and re-isolates telep1, breaking wired→Wi-Fi mDNS/AirPlay.
Undo the Double-NAT — bridge/DMZ the upstream TP-Link NE200 5G NR cellular FWA CPE so this router holds the WAN address directly. Would remove the double-NAT and could restore genuine IPv6 (currently disabled on the LAN, see IPv6 disabled on the LAN (2026-07-28)). NB the NE200’s WAN is CGNAT (10.x), so a public inbound path still would not exist without carrier cooperation.
2026-08-31-cams-vlan-device-claim-failed-wifi-reload — a SECOND wifi reload cams outage: cams stuck DEVICE_CLAIM_FAILED, ifup cams couldn’t clear it, only /etc/init.d/network restart did; cams-guard being hardened to escalate
2026-08-26-router-reflash-mac-5ghz-dfs-and-bambu-offline — after a reflash: SSH host-key/authorized-keys reset (re-add to /etc/dropbear/authorized_keys), a Mac couldn’t see the DFS-channel 5 GHz SSID, and the Bambu H2S dropped offline