Mid-incident? Do this first

Reach the router over Tailscale (the LAN is down, so MagicDNS won’t resolve — use the raw IP):

ssh root@100.69.112.32
logread | grep -i 'dnsmasq\['

Look for FAILED to start up / duplicate dhcp-host. #1 cause = dnsmasq refused to start on telep-router — a single bad dhcp-host (duplicate reservation IP/MAC) or any config error kills DHCP and DNS for the entire site.

Symptoms

  • Devices can’t join WiFi, or join but get no IP (169.254.x self-assigned / “no internet”).
  • Internet is gone for everyone; multiple homelab devices drop offline at once.
  • The mainframe (telep-mainframe, .123) and other hosts fall off Tailscale (they lost their LAN lease).

Diagnose → Fix

  1. Reach the router over Tailscale (LAN/DNS is down):
    ssh root@100.69.112.32
  2. Check the dnsmasq log for a fatal start error:
    logread | grep -i 'dnsmasq\['
    A duplicate reservation logs duplicate dhcp-host IP address … FAILED to start up.
  3. Validate the config and confirm the daemon is (not) running:
    dnsmasq --test
    pgrep -x dnsmasq
    --test reports the exact bad line; empty pgrep = dnsmasq is down = no DHCP, no DNS.
  4. If a duplicate/bad reservation — find and delete the offending section:
    uci show dhcp | grep -iE '<ip>|<mac>'
    uci delete dhcp.<section>       # e.g. uci delete dhcp.telep_tv
    uci commit dhcp
    /etc/init.d/dnsmasq restart
  5. Verify DHCP is listening and leases are flowing:
    pgrep -x dnsmasq                 # now returns a PID
    netstat -lnup | grep :67         # DHCP server listening
    cat /tmp/dhcp.leases             # clients re-appear within ~1 min
    Clients re-lease automatically; the mainframe reclaims .123 and returns to the tailnet within a minute.

NEVER add a dhcp-host reservation without checking for a collision first

uci show dhcp | grep -iE '<ip>|<mac>'

dnsmasq does not silently ignore a duplicate dhcp-host IP — it treats it as fatal and refuses to start entirely. The canonical mainframe reservation already exists: dhcp.@host[2], name telep-mainframe, mac d8:5e:d3:a7:05:d6, ip 192.168.1.123. The AirPlay telep-tv receiver is the mainframe (same NIC/MAC) — do not add a separate telep-tv reservation. That exact mistake caused an 8.5 h site-wide outage on 2026-08-15.

  • Duplicate dhcp-host (most common) — full post-mortem, exact log lines, and the delete-fix: 2026-08-15-dhcp-outage-duplicate-reservation-postmortem.
  • Any bad dnsmasq config restart — e.g. a botched blocklist/wildcard edit. dnsmasq restarts on every uci commit dhcp; a bad commit = same site-wide outage. The 2026-08-03 casino-blocker deploy did exactly this and forced a factory reset: 2026-08-03-telep-router-factory-reset-recovery.
  • A single host is offline (not the whole site) → not this runbook; see host-offline.
  • Router survives outages because it’s on the UPS; if the router itself is dead/rebooting, WiFi is down too — see telep-router.