Issue 194 resolved: the fixed host forgot its former archive on all four machines

2026-10-02 11:31:29 +02:00
3 changed files with 9 additions and 54 deletions
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-02
 located-in: [mesh-host internal/apply (removeOrphan: a former target of a kind with no removal was fatal), mesh-host internal/store (Record keeps a former target for every kind, the host's own archive included)]
-fixed-by:
+fixed-by: mesh-host 65 — a former target of a kind the host cannot remove is left in place, said and forgotten; a dropped archive still refuses
 amended-design:
 ---

@@ -62,3 +62,10 @@ because the alternative was four machines that could apply nothing.
 - Is there a bed that replaces a host under the current rules before the live mesh does
  (the proof row of [ADR 0141](../../02-DECISIONS/0141-the-host-delivers-its-own-successor.md) was
  a single crossover, before former targets existed)?
+
+## Resolved, 2026-10-02
+
+mesh-host 65, merged 07:35Z. Recovered as the record above says: the operator dropped the one
+`@former:` entry from each machine's host record and pushed; the fixed host then ran on all four and
+its first apply said `forgotten mesh-host.next@former:… a former target left in place` and applied the
+rest. The open questions stand as questions for the host's own versions, not as faults.
@@ -1,38 +0,0 @@
---
-status: located
-opened: 2026-10-02
-located-in: [mesh-host internal/outward (Links reported only the links carrying a default route)]
-fixed-by:
-amended-design: []
---
-
-# 197 — A physical link that is down is not filtered when it comes up
-
-## What was observed
-
-A sweep of every machine's filter on 2026-10-02. A laptop-class machine connected by its radio has a
-wired port that was unplugged. Its filter guarded the radio and the tunnel, and accepted everything
-arriving on any other link:
-
-```
-iifname != { "mesh0", "<radio>" } accept
-```
-
-The wired port was not in the list. Plugged in, everything arriving on it would have been accepted,
-every port of the machine open to whatever network the cable reached. That would last until the
-machine reported again and was pushed a new filter.
-
-## Why it matters
-
-**The filter's one rule about links fails open.** [ADR 0140](../../02-DECISIONS/0140-the-filter-constrains-what-arrives-from-outside.md)
-has the filter constrain what arrives from outside, and has the machine say which links face outside.
-Everything not named is treated as the machine's own, its containers and bridges. So a link the machine
-fails to name is not filtered at all. The host named only the links carrying a default route at the
-moment it reported. A cable plugged in later is the ordinary case for a laptop. A second wired network
-that never carries the default route, such as a direct link to a storage box, is never named at all.
-
-## Open questions
-
- A virtual link that faces outside (a VPN client's interface, a USB tether that appears as a virtual
-  device) has no physical device behind it. It is named only while it carries the default route. Is
-  that enough?
@@ -1,14 +0,0 @@
-# Diagnosis
-
-*2026-10-02.*
-
-**Located in `mesh-host` `internal/outward`.** `Links` read the kernel's routing tables and returned the
-interfaces carrying a default route. An unplugged port carries none, so it was never reported, and the
-controller rendered the filter around the links it was given.
-
-**The fix.** A link faces outside if it carries a default route **or** has a physical device behind it.
-The kernel lists every interface under `/sys/class/net`, with a `device` entry for one backed by
-hardware. A bridge, a veth, the tunnel and the loopback have none, so they stay the machine's own. The
-wired port is now reported up or down, and the filter guards it before anything is plugged in. Tested
-with a radio carrying the default route and an unplugged wired port beside a bridge, a veth, the docker
-bridge, the tunnel and the loopback: the two physical links are reported, nothing else.