Files
hq/04-ISSUES/154-a-machines-own-network-is-not-a-reach/00-report.md
T
jschoubben b967ef7be3 Two records shared a number, twice, and every check passed
Two machines filing issues in the same hour both read main correctly and
both took "the next free number". main lags every open pull request —
seven that evening — so they collided twice. The second collision
reached main with records, cycle and index all reporting success.

cycle.py now refuses a tree where two issue folders share a leading
number, and names both. Proven by adding a duplicate and watching it
fail. The colliding records become 153 and 154, renumbered in the branch
that lands last, because renumbering a branch whose author is still
pushing only moves the race.

The check catches a collision; it does not prevent one. Taking a number
still means reading the open pull requests as well as main — issue 155
says so.
2026-09-29 23:38:48 +02:00

1.9 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
open 2026-09-29
hq 02-DECISIONS/0138 (reach
internal | public | both)
mesh-controller internal/catalogue/filtering.go (Reaches)

154 — A machine's own network is not a reach

What was observed

Preparing ace's modules. ace sits on a home network (192.168.1.0/24) behind a router, and several of its services are reached from that network by devices that will never be mesh machines:

  • mosquitto 1883 — an IoT light switch (sonoff-office-light-switch) and home-assistant;
  • unifi 8080/3478 udp/10001 udp — the access points' inform, STUN and discovery;
  • plex 32400 — LAN streaming clients (three connected at survey time);
  • home-assistant 8123, and the resolver on the LAN address.

ADR 0138 gives an endpoint's reach as internal (the private overlay), public (anywhere) or both. None of them says this machine's own network. The predecessor could: its unifi manifest opened inform/STUN/discovery from: 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12.

Consequence

The only reach that includes a LAN device is public. While ace is adopted that is harmless — its own firewall stays and admits the LAN — and behind NAT "anywhere" happens to mean the LAN. But:

  • it states the wrong thing: an operator reading reach: public on an IoT broker believes it is on the internet, and a router port-forward added later for something else makes it so;
  • at converge ace, the mesh's filter is the sum of what it listens on (ADR 0045). An endpoint left internal cuts every LAN device off at the flip; one set public opens it to the internet on any machine with a public address.

What would be right (for diagnosis)

A reach — or a source — that means the networks the machine is directly attached to (its uplink's subnets, as the machine reports them), so a LAN-only service is declared as exactly that and the filter can admit it without admitting the internet.