TP25 Fund E: Hebel 1 gescheitert, TP27 durchgezogen, Fund B entwarnt

Zwei von Christoph gemeldete Ausfaelle (13:16 Terrasse, 14:23 Arbeitszimmer)
stehen im Kollektor und tragen dieselbe Signatur: Reauth-Schwall, dann ein
Loch von 7 bzw. 5,5 Minuten. Beide liegen NACH dem Hebel von 08:09.

- Hebel 1 (ft-over-ds=no) hat nicht gegriffen: 124x reauthenticating nach
  dem Eingriff, Stundenvergleich auf gleicher Firmware 07h=79 vs 14h=70.
  Erfolgskriterium war ~0. Gewertet wird nur 08:09-14:36 (Christoph-Entscheid),
  danach kommt das Upgrade als zweite Variable dazu. Transaktion bleibt OFFEN,
  Compliance bleibt bewusst 134/135.
- TP27 erledigt: Flotte einheitlich auf 7.24.1 (ap2 08:56, core 14:36,
  ap1 14:50, branch 14:52; ap3 kam bereits so). Nach dem Upgrade live geprueft:
  3 CAPs Ok, 4 Provisioning-Regeln, ap2 9x running, 30 Clients, ft-over-ds=no
  hat den Reboot ueberlebt.
- Fund B entwarnt: die 13 CAP-joined / 4 activity timeout waren die
  Upgrade-Reboots, keine CAPWAP-Instabilitaet. Neuer Gotcha: ein Burst ueber
  VIELE MACs ist Infrastruktur, ueber EINE MAC ein Client.
- Zweiter Gotcha: die cap-wifiN-Karte verschiebt sich bei JEDEM Rejoin, nicht
  nur beim Provisionieren -- sie wanderte an einem Tag zweimal, womit die
  Tabelle im Vormittags-Handoff nach sechs Stunden falsch war. Interface-Namen
  in Logzeilen sind ohne zeitnahen Snapshot nicht zuschreibbar.
- Offen fuer die naechste Session: Hebel 2 (ft=no) ODER wpa2-psk,wpa3-psk --
  sec-main ist auch die einzige SSID ohne wpa2-psk, und "association rejected,
  no cached PMK" (157x am 31.08., 0x am 30.08.) ist eine SAE/PMKSA-Meldung.
  Vorher pruefen, ob 7.24.1 das Verhalten schon veraendert hat.
- wifi-p750w-coverage-and-map.md ist vom 2026-07-02 und als Coverage-Beleg
  unbrauchbar (vor CAPsMAN-Cutover, vor ap2-Umzug, vor ap3).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-31 15:27:57 +02:00
parent 6f8ba8c8b5
commit 0680ccabc8
4 changed files with 222 additions and 30 deletions

View File

@@ -53,8 +53,9 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
Backups: `docs/cf-backup/*-20260830-vor-tp16.3-schnitt.json`.
- 🆕 **Globale Verhaltensregeln konsolidiert (2026-08-29, TP35 Schicht 3):** `~/.config/opencode/AGENTS.md` ist jetzt die **SSoT** für globale Verhaltensregeln (Secrets, VLAN-Schema, 5 Lessons, SoC, Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis, Backup-Guard). `~/.claude/CLAUDE.md` hält denselben Block als Claude-Code-Spiegelung mit Verweis auf die SSoT. opencode liest AGENTS.md mit Vorrang vor `~/.claude/CLAUDE.md`.
- **Alle vier MikroTik laufen auf RouterOS 7.24** (stable, 2026-08-17 von Christoph selbst gehoben, TP27),
**RouterBOOT ebenfalls 7.24** auf allen vieren (`current-firmware` = `upgrade-firmware`, geprüft 08-18).
- **Alle fünf MikroTik laufen auf RouterOS 7.24.1** (🆕 **Angleichung am 2026-08-31 von Christoph
selbst durchgezogen, TP27 damit erledigt** — ap2 08:56, core 14:36, ap1 14:50, branch 14:52;
ap3 kam bereits so). Vorher: vier auf 7.24 (08-17), nur ap3 auf 7.24.1.
- **L3 + WAN-Edge = `crs326-core`** (CRS326-24G-2S+, Technik UG): Routing, DHCP (7 Server,
54 Reservierungen), DNS, NAT, **NTP-Server für den Standort** und der WG-Hub (TP10, Peers `fm`/`dw`)
laufen hier. Mgmt-SVI **`10.40.99.1`** (vlan99), Gateway `.1` je VLAN. **WAN = `vlan100`** — DHCP-Client
@@ -72,7 +73,7 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
🆕 **Dritter AP `ap3` (cAP ax) ✅ LIVE seit 2026-08-30** (TP28 dafür wieder geöffnet):
`10.40.99.13`, Uplink `ether1` → **core `ether21`** (Trunk), reiner CAP, **RouterOS 7.24.1**
(die anderen vier auf 7.24 — Angleichung ist ein eigener TP27-Durchgang). Kanäle
(🆕 **seit 2026-08-31 die ganze Flotte** — die frühere Versionsdifferenz ist aufgelöst). Kanäle
**`5180/ax/Ce/I`** + **`2437/ax`** (ch6) nach dem TP25-Plan vom 2026-08-24, am Gerät nachgemessen.
🔴 **ap1 ist funkstill** — es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und würde
auf 5180 kollidieren; es hat deshalb bewusst **keine Provisioning-Regel** am Manager, bleibt aber
@@ -109,16 +110,27 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
`system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
nicht diagnostizierbar.
- 🔬 **TP25 Fund E — Hebel 1 läuft seit 2026-08-31 08:09 (LAUFENDER VERSUCH, nicht Endstand):**
`sec-main` steht am Core auf **`ft=yes ft-over-ds=no`** (vorher `yes/yes`). Belegt am Manager an
allen vier aktiven Master-VAPs (`cap-wifi3/4/5/6`). Transaktion
**`TP25-fund-e-ft-over-ds`** ist **OFFEN** (Scope `wifi-security`, Ablauf **2026-09-03**),
- 🔴 **TP25 Fund E — Hebel 1 ist GESCHEITERT (Stand 2026-08-31 nachmittags):** `sec-main` steht am
Core auf **`ft=yes ft-over-ds=no`** (seit 08:09), aber das Symptom blieb: **124× `reauthenticating`
nach dem Eingriff** und **zwei von Christoph erlebte Ausfälle** — 13:16 (Videocall bricht ab,
7 min ohne WLAN) und 14:23 (5,5 min, nur durch WLAN-Toggle beendet). Stundenvergleich auf
gleicher Firmware: **07:00–08:00 = 79 · 14:00–15:00 = 70**. Erfolgskriterium war „~0" ⇒ nicht
eingetreten. Gewertet wird bewusst nur **08:09–14:36** (danach kommt das TP27-Upgrade als zweite
Variable dazu; Christoph-Entscheid: „Vormittag als Ergebnis werten").
⇒ Transaktion **`TP25-fund-e-ft-over-ds` bleibt OFFEN** (Ablauf **2026-09-03**), **Compliance
weiter bewusst 134/135**; Rollback oder Commit ist eine Entscheidung, kein Aufräumen.
Geräte-Backup `pre-tp25-funde-ftoverds.backup` liegt auf dem Core.
⇒ **Compliance steht deshalb bewusst auf 134/135** — der eine Drift ist genau dieser Versuch und
wird von `gc-transaktion.py status` als *erwartet* ausgewiesen. **135/135 kommt beim COMMIT
zurück**, nachdem 24 h gemessen sind und das Template nachgezogen ist; das Skript verweigert den
Commit ohnehin, solange der Scope driftet. Baseline zum Vergleich: **93× `reauthenticating`**,
93/93 vom iPhone `F2:62:4C:E1:AF:09`, 93/93 auf `dirtyvader-main`.
**Nächste Entscheidung:** Hebel 2 (`ft=no`) **oder** `authentication-types=wpa2-psk,wpa3-psk` —
`sec-main` ist auch die einzige SSID ohne `wpa2-psk`, und `association rejected, no cached PMK`
(157× am 31.08., 0× am 30.08.) ist eine SAE/PMKSA-Meldung. **Vorher prüfen, ob 7.24.1 auf dem
Manager das Verhalten schon verändert hat** — zwischen 14:37 und 15:12 stand nur **1**
`reauthenticating` im Log, keines vom iPhone (35 min = noch keine Aussage).
Details: [`handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](handoff-20260831-tp27-upgrade-und-hebel1-befund.md).
- ⚠️ **Messfalle, die diese Session fast erwischt hat:** die 13 CAP-`joined`/`activity timeout` vom
31.08. sahen nach CAPWAP-Instabilität aus — es waren die **Reboots des TP27-Upgrades**. Und die
**`cap-wifiN`-Karte hat sich an einem Tag zweimal verschoben** (08:09, 14:36), womit die im
Vorgänger-Handoff festgehaltene Tabelle nach sechs Stunden falsch war. Interface-Namen in
Logzeilen sind ohne zeitnahen Karten-Snapshot **nicht zuschreibbar**.
- **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 5 Geräte in der Registry),
**Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
**135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30;
@@ -1672,8 +1684,8 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört
`vlan99`, Flotten-PW) über das Kabel, Phase 2 (Werks-WLAN weg, CAP-Modus,
`slaves-datapath`, `vlan-filtering=yes`) über `vlan99`.
- ✅ **RouterOS 7.20.8 → 7.24.1 + RouterBOOT 7.24.1** (zwei Reboots, TP27-Kriterium
`current-firmware = upgrade-firmware`). ⚠️ Die anderen vier stehen auf **7.24**; die
Angleichung auf 7.24.1 ist ein eigener TP27-Durchgang (Core-Reboot = Standort-Ausfall).
`current-firmware = upgrade-firmware`). 🆕 **Die Angleichung der übrigen vier ist am
2026-08-31 erfolgt** (Christoph, WebFig) — die Flotte ist einheitlich, TP27 erledigt.
- ✅ **ap1 funkstill** (Provisioning-Regeln entfernt + `remote-cap provision`), gegengeprüft
**am CAP**: nur noch `wifi1`/`wifi2` mit `running=false`, keine dynamischen VAPs.
- ✅ **ap3 funkt**: `cap-wifi5` = **`5180/ax/Ce/I`**, `cap-wifi6` = **`2437/ax`**, voller