Levandor

Post-mortem — Total DHCP/DNS Outage from a Duplicate dhcp-host Reservation

3 min read

Whole-site LAN/WiFi outage (~8.5 h) caused by adding a duplicate dhcp-host for IP 192.168.1.123 on telep-router — dnsmasq treats a duplicate reservation IP as a fatal error and refuses to start, taking down DHCP and DNS for the entire network.

LESSON — a duplicate dhcp-host IP kills the whole network, it is not ignored

Before adding ANY dhcp-host reservation on OpenWrt, CHECK for an existing entry with the same IP or MAC:

uci show dhcp | grep -iE '192\.168\.1\.123|d8:5e:d3:a7:05:d6'

dnsmasq does not silently ignore a duplicate dhcp-host IP — it logs duplicate dhcp-host IP address … FAILED to start up and refuses to start at all, so DHCP (:67) and DNS (:53) go dead site-wide. No client can get or renew a lease.

The canonical reservation dhcp.@host[2] (name telep-mainframe, mac d8:5e:d3:a7:05:d6, ip 192.168.1.123) already exists — do NOT re-add it under any other name.

Symptoms

  • Entire LAN and WiFi unusable — no client could obtain an IP.
  • The mainframe (telep-mainframe) plus ~a dozen homelab tailnet devices dropped offline for ~8.5 hours.
  • The mainframe couldn’t renew its DHCP lease, lost 192.168.1.123, and fell off Tailscale with it.

Root Cause

While adding a DHCP reservation for the AirPlay receiver (telep-tv), a second dhcp-host for the same IP was created on telep-router:

  • Existing canonical reservation: dhcp.@host[2] → name telep-mainframe, mac d8:5e:d3:a7:05:d6, ip 192.168.1.123.
  • Newly added duplicate: named section dhcp.telep_tv → same mac d8:5e:d3:a7:05:d6 + same ip 192.168.1.123.

dnsmasq validates reservations on startup. A duplicate dhcp-host IP is a fatal config error:

dnsmasq: duplicate dhcp-host IP address 192.168.1.123 …
dnsmasq: FAILED to start up

Because dnsmasq would not start at all, it served no leases and answered no DNS — DHCP and DNS both dead for the whole site. This is not a partial/degraded failure; the daemon is simply down.

Fix

uci delete dhcp.telep_tv
uci commit dhcp
/etc/init.d/dnsmasq restart

dnsmasq came back cleanly; DHCP (:67) and DNS (:53) restored. The mainframe re-leased .123 and returned to the network (and Tailscale) within a minute.

Recovery Access (when the LAN is down)

Reach the gear over Tailscale, not the LAN

When DHCP/DNS/LAN is down, use the tailnet IPs directly — MagicDNS may not resolve without the router’s DNS:

Do not confuse the LAN hosts:

  • Mainframe LAN IP 192.168.1.123 (enp5s0), mac d8:5e:d3:a7:05:d6
  • Raspberry Pi (raspi / KrakenSDR rig) LAN IP 192.168.1.200

Aftermath

  • The mainframe had rebooted ~8.5 h earlier (uptime confirmed) and then sat network-dead the whole time due to the dnsmasq outage.
  • After the DHCP fix it recovered; camwall and uxplay resumed. camwall.service was bounced so its 4 mpv panes reconnect to go2rtc as cameras rejoin the telep-cc WiFi (camera .139 back first, C302 .168 reconnecting).

The telep-tv reservation goal is now MOOT

Do NOT add a separate telep-tv DHCP reservation

The AirPlay telep-tv receiver is the mainframe (same host, same NIC/MAC). The existing telep-mainframe reservation (dhcp.@host[2], .123, d8:5e:d3:a7:05:d6) already covers that MAC/IP. Adding a second reservation for it is exactly what caused this outage.

Graph View

Backlinks