Files
command-center/omp-docs/system/network.md
Frank f1e0b6583d docs: distill the retired workstation's KB pages into general pages
Frank's call: no per-host graveyard. The four /system/dankware/ pages carried
two pieces of knowledge that outlive the box, and one that does not.

Distilled:
- omp-docs/system/network.md (new) — LAN topology plus the multi-link resolver
  law: a client with two +DefaultRoute links flaps its DNS, and the fix is a
  static per-connection resolver, not resolved.conf. Keeps the
  flush-caches-loop verification, because one successful dig proves nothing.
- omp-docs/tools/niri/displays.md (new) — the multi-monitor rig: portrait
  transforms, absolute positions, auto-placed third panel, the iGPU
  render-node pin, and the three failure modes (duplicate output blocks,
  positions that do not reflow, a mode the panel cannot drive).

Dropped: the machine's own spec sheet (CPU/GPU/PCI/NVMe inventory for a box
Frank sold) and its quick-facts table. The OS and userspace facts it repeated
already live in tools/cachyos.md.

omp-docs/system/dankware/ moved to .AGENTTRASH/20260928-retired-workstation/
(not deleted; git history holds it too). system/index.md and the niri index
repoint; niri's [[displays]] wikilink now resolves to the new page instead of
the trashed one. kb-lint: 0 violations.
2026-09-28 16:15:57 -07:00

3.2 KiB

type, title, description, tags, verified
type title description tags verified
reference Network LAN topology for the fleet and the client-side DNS pinning rule for multi-homed Linux workstations.
network
dns
systemd-resolved
workstation
unverified
2026-08-28

Network

How the LAN is addressed, which host answers what, and the one DNS rule that bites every Linux workstation with both Wi-Fi and Ethernet plugged in.


Topology

Host IP Role
Router 192.168.0.1 DHCP; hands out the DNS server to clients
Dankclaw 192.168.0.143 Pi-hole DNS, Caddy edge, Gitea, large inference model
Dankserver 192.168.0.235 small inference model
Clients DHCP from 192.168.0.0/24 workstations, phones

The router hands clients 192.168.0.143 as their DNS server; Pi-hole answers every *.franksdank.cloud name with the LAN address of the box that serves it. Names that resolve to the public WAN address time out on the LAN because the G36 has no NAT loopback — a symptom that looks like "the network is down" and is not. Full DNS mechanics live in the serverAppConfigs knowledge base (Infrastructure/LAN-DNS.md); this page is the client-side view.


A Linux client with two +DefaultRoute links will flap its DNS.

NetworkManager marks both a wired and a Wi-Fi connection as default routes. Both get the same DHCP DNS list from the router, and systemd-resolved resolves queries against one "current" resolver per link. When the links disagree — one landed on the Pi-hole address, the other on a DHCP-provided upstream that answers with the public WAN IP — every lookup can return a different address, and half of them time out on the LAN.

Enumerate the links and their resolvers before changing anything:

nmcli -t -f NAME,DEVICE connection show --active   # one entry per default link
resolvectl status                                 # per-link "Current DNS Server"
ip -br addr

The fix is to pin the LAN resolver on each connection, because /etc/systemd/resolved.conf's DNS= is only a per-link fallback and does not override what the link itself was handed:

for c in "<wired connection>" "<wifi connection>"; do
  nmcli connection modify "$c" ipv4.method auto \
    ipv4.dns 192.168.0.143 \
    ipv4.ignore-auto-dns yes \
    ipv4.ignore-auto-routes no
done
nmcli connection up "<wired connection>"
nmcli connection up "<wifi connection>"
systemctl restart systemd-resolved

method auto keeps DHCP for address, gateway, and routes; ignore-auto-dns yes makes the static resolver the only one used; ignore-auto-routes no keeps the DHCP routes, so the dual-default traffic path survives.

Verify with a cache-clear loop — the name must return the LAN address on every run, not on average:

for i in $(seq 1 10); do resolvectl flush-caches; dig romm.franksdank.cloud +short; done

A single successful dig proves nothing on a flapping resolver.


Servers

See Also