diff --git a/04-ISSUES/196-the-hub-relays-only-the-ports-it-publishes-itself/00-report.md b/04-ISSUES/196-the-hub-relays-only-the-ports-it-publishes-itself/00-report.md
index 5adf602..cbe2c41 100644
--- a/04-ISSUES/196-the-hub-relays-only-the-ports-it-publishes-itself/00-report.md
+++ b/04-ISSUES/196-the-hub-relays-only-the-ports-it-publishes-itself/00-report.md
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-02
 located-in: [mesh-controller internal/catalogue/filtering.go (AsNftables: the forward chain has no rule for the mesh passing through, so a relayed packet is judged by this machine's own published ports)]
-fixed-by:
+fixed-by: mesh-controller PR 209 (the forward chain relays what comes in and goes out on the tunnel), live 2026-10-02
 amended-design: []
 ---
 
@@ -45,3 +45,10 @@ same day, and that explanation fit well enough that the per-port pattern was not
   mesh? That would duplicate the target's rules on the hub.
 - No test raises two machines behind a hub and checks a port between them that the hub does not
   publish. The lab's beds have one machine per site.
+
+## Resolved (2026-10-02)
+
+Live on all four machines after one push each. The same sweep, from both home machines to the third
+over the mesh: 45 of 55 ports answer, the same 45 the hub reaches directly. The 9 that do not are
+ports the target opens to nobody on the mesh, and one is refused because it listens only on a LAN
+address. Nothing answers that the target's rules do not open.