Merge main + nervous-williams; Drift-Zuschreibung korrigiert
Der Branch enthaelt jetzt origin/main (0680cca, TP25 Fund E / TP27) und die Korrekturc8b2a15aus claude/nervous-williams-acf000. Inhaltliche Korrektur an meinen eigenen Dateien - Ich hatte die wifi-security-Drift (ft-over-ds=no auf sec-main) dem 7.24.1-Upgrade zugeschrieben. Falsch: gc-transaktion.py status fuehrt TP25-fund-e-ft-over-ds als OFFEN -- der Hebel wurde 08:09 bewusst gesetzt, der Core erst 14:36 gehoben. Sie gehoert einer laufenden TP25-Session, braucht keine Entscheidung und darf nicht gruen gemacht werden. Korrigiert im §5-Prompt und im §2/§3-Handoff. - Merkregel in CLAUDE.md: vor jeder Drift-Bewertung gc-transaktion.py status lesen. Dazu die Abgrenzung Transaktion (befristeter Versuch) vs. Soll/Template (Dauerzustand) -- die sechs AP-Drifts aus TP16.3 §3.4 sind Dauerzustand und gehoeren deshalb ins Template, nicht in eine Transaktion. - Notiert: gc-transaktion.py findet den Token aus einem Worktree heraus nicht (210-nautobot.yml liegt nur im Haupt-Checkout); die Transaktionsliste kommt trotzdem, nur die Compliance-Spalte fehlt. Konflikt in teilprojekte.md (ROS-7.24.1-Zeile) zusammengefuehrt statt eine Seite zu verwerfen: TP27-Erledigung samt Zeitstempeln aus main plus die npk-Folge fuer TP16.3 aus diesem Branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -33,12 +33,18 @@ Nach vollem Refresh (Backup → Intended → Compliance, **nicht** die stale Zah
|
||||
|---|---|---|
|
||||
| ap1 / ap2 / ap3 | `ip-address` | `/ip address add address=172.17.0.1/24 interface=veth-cf` |
|
||||
| ap1 / ap2 / ap3 | `ip-firewall-nat` | `masquerade`, Kommentar `TP31: cloudflared egress` |
|
||||
| crs326-core | `wifi-security` | `ft-over-ds` — **die bekannte, unverändert** |
|
||||
| crs326-core | `wifi-security` | `ft-over-ds` — **offene Transaktion `TP25-fund-e-ft-over-ds`**, kein Versehen |
|
||||
|
||||
**Ursache ist ein Widerspruch zwischen zwei Dokumenten**, kein Ausrutscher: Runbook §3.4 schreibt
|
||||
Direkt-Writes für `veth`/`ip address`/`nat` vor, die Governance stellt `/ip address` und
|
||||
`/ip firewall` unter GC-Pflicht. Ich bin dem Runbook gefolgt.
|
||||
|
||||
⚠️ **Korrektur 2026-08-31 (nachgetragen):** die siebte Drift wurde hier zuerst dem 7.24.1-Upgrade
|
||||
zugeschrieben — falsch. `gc-transaktion.py status` führt **`TP25-fund-e-ft-over-ds` als OFFEN**
|
||||
(gesetzt 08:09, Core-Upgrade erst 14:36). Sie ist Absicht einer laufenden Messung und braucht **keine**
|
||||
Entscheidung. **Merkregel: vor jeder Drift-Bewertung `gc-transaktion.py status` lesen** — Drift aus
|
||||
einem laufenden Versuch sieht identisch aus wie ein Versehen.
|
||||
|
||||
**Die sechs Drifts sind inhaltlich richtig** — die Config *soll* dort stehen, ohne sie läuft kein
|
||||
Container. Der saubere Weg ist, sie ins **Soll** zu heben (AP-Template bzw. ConfigContext
|
||||
`ap-common`), damit die Compliance sie als konform sieht.
|
||||
|
||||
162
docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md
Normal file
162
docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md
Normal file
@@ -0,0 +1,162 @@
|
||||
# Handoff 2026-08-31 nachmittags — TP27 durchgezogen, Hebel 1 gescheitert, Fund B entwarnt
|
||||
|
||||
> Vorgänger: [`handoff-20260831-fund-e-hebel1-gezogen.md`](handoff-20260831-fund-e-hebel1-gezogen.md)
|
||||
> (Eingriff + Abnahme). **Dieses Dokument ist der Stand danach** und löst ihn als aktuellen Zeiger ab.
|
||||
> Anlass war eine Nutzermeldung, nicht ein geplanter Messtermin.
|
||||
|
||||
## Ausgangspunkt: zwei erlebte Störungen mit Uhrzeit
|
||||
|
||||
Christoph hat zwei Vorfälle gemeldet und dazu — entscheidend — **Standort und Bewegung**:
|
||||
|
||||
| Zeit | Situation | Was er sah |
|
||||
|---|---|---|
|
||||
| **13:16** | Terrasse, Telefon in der Halterung, **unbewegt** | Telegram-Videocall bricht ab, „schwaches Signal", danach 5G |
|
||||
| **14:23** | Arbeitszimmer, kurz zuvor gewechselt, **unbewegt** am Schreibtisch | iPhone auf 5G, scannt dauernd, `-main` sichtbar, Verbinden schlägt fehl. **Behoben durch WLAN aus/ein.** |
|
||||
|
||||
Beide stehen im Kollektor, beide mit derselben Signatur — **Reauth-Schwall, dann ein Loch:**
|
||||
|
||||
```
|
||||
13:08:37–13:08:42 10 × reauthenticating 13:09:12 weg, −77
|
||||
→ 7 Minuten kein WLAN ← der Call-Abbruch
|
||||
14:17:47–14:18:07 4 × reauthenticating 14:18:29 weg, −72
|
||||
→ 5,5 Minuten kein WLAN ← „scannt, verbindet nicht"
|
||||
14:23:54 connected, −71 ← der WLAN-Toggle
|
||||
14:23:57–14:28:47 70 × reauthenticating auf dem anderen Radio
|
||||
```
|
||||
|
||||
**Der Toggle hat also nicht „reparariert", sondern eine Assoziation erzwungen** — das Hämmern lief
|
||||
danach auf dem zweiten Radio noch fünf Minuten weiter.
|
||||
|
||||
## 🔴 Ergebnis: Hebel 1 (`ft-over-ds=no`) hat NICHT gegriffen
|
||||
|
||||
Der Hebel wurde um **08:09** gezogen. Beide Vorfälle liegen **danach**.
|
||||
|
||||
| Fenster | `reauthenticating` |
|
||||
|---|---|
|
||||
| 07:00–08:00 (**vor** dem Hebel) | **79** |
|
||||
| 14:00–15:00 (**nach** dem Hebel) | **70** |
|
||||
| gesamt nach 08:09 bis 14:36 | **124** |
|
||||
|
||||
Vergleichbare Tagesstunden, praktisch unveränderte Rate, dazu zwei erlebte Ausfälle. Das
|
||||
Erfolgskriterium des Vorgänger-Handoffs lautete „geht auf ~0 zurück" — **nicht eingetreten.**
|
||||
|
||||
⚠️ **Gewertet wird bewusst nur das Fenster 08:09–14:36** (6,5 h auf unveränderter Firmware).
|
||||
Ab 14:36 kommt eine zweite Variable dazu, s. u. — Christoph-Entscheid 2026-08-31: „Vormittag als
|
||||
Ergebnis werten". Das ist keine 24-h-Messung, aber für ein **Negativ**-Ergebnis mit zwei erlebten
|
||||
Ausfällen belastbar.
|
||||
|
||||
## ✅ TP27 ist durchgezogen — die Flotte steht komplett auf 7.24.1
|
||||
|
||||
Von Christoph selbst, über WebFig vom MacBook (`10.40.10.82`), rollierend über den Tag:
|
||||
|
||||
| Gerät | Version | Reboot ca. |
|
||||
|---|---|---|
|
||||
| ap3 | 7.24.1 | gestern (kam schon so) |
|
||||
| ap2 | 7.24.1 | **08:56** |
|
||||
| crs326-core | 7.24.1 | **14:36** |
|
||||
| ap1 | 7.24.1 | **14:50** |
|
||||
| crs326-branch | 7.24.1 | **14:52** |
|
||||
|
||||
Die Doku-Zeile „Flotte auf 7.24, ap3 auf 7.24.1 — Differenz bewusst" ist damit **überholt**;
|
||||
die Angleichung, die als eigener TP27-Durchgang vorgemerkt war, ist erledigt.
|
||||
|
||||
**Zustand nach dem Upgrade, live geprüft (15:1x):**
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| CAPs | 3 × `state=Ok`, alle 7.24.1 |
|
||||
| Provisionierung | 4 Regeln (ap2 5G/2,4G, ap3 5G/2,4G) unverändert; ap1 bewusst ohne |
|
||||
| VAPs am CAP gelesen | ap2: 9 × `running=yes` |
|
||||
| Clients | 30 |
|
||||
| Transaktion überlebt? | `sec-main`: `ft=yes ft-over-ds=no` ✓ |
|
||||
| Core-Ressourcen | 435 MiB frei, CPU 8 % |
|
||||
|
||||
## ✅ Fund B (vermeintliche CAPWAP-Instabilität) ist ENTWARNT
|
||||
|
||||
Beim Nachsehen fielen 13 × `joined`, 4 × `activity timeout`, 3 × `connection interrupted` auf —
|
||||
das sah nach einem Manager-CAP-Problem aus, das alle Clients trifft. **Es war das Upgrade.**
|
||||
Jedes Ereignis fällt auf einen Reboot aus der Tabelle oben. Die Massenbursts
|
||||
`association rejected, no cached PMK` (74 Zeilen, 38 verschiedene MACs, um 08:08 und 14:33)
|
||||
sind Re-Provisionierungen, kein Defekt.
|
||||
|
||||
🔴 **Merkregel daraus:** ein Burst über **viele** MACs ist ein Infrastruktur-Ereignis, ein Burst über
|
||||
**eine** MAC ein Client-Ereignis. Vor jeder Client-Diagnose erst `grep " caps,"` und `uptime` lesen —
|
||||
sonst sucht man einen Gerätefehler, der ein geplanter Reboot war.
|
||||
|
||||
## Neue Beobachtungen, die in der Auswertung morgen gebraucht werden
|
||||
|
||||
**1. Die Logzeile `association rejected, no cached PMK` ist neu** — 157 × am 31.08., **null** am
|
||||
30.08. Sie benennt die PMK-Caching-Achse ausdrücklich. Der überwiegende Teil sind Reboot-Folgen
|
||||
(s. o.), aber nicht alle.
|
||||
|
||||
**2. Die `cap-wifiN`-Karte hat sich seit 08:09 ERNEUT verschoben.** Die Tabelle im Vorgänger-Handoff
|
||||
ist bereits wieder falsch:
|
||||
|
||||
| | Handoff-Stand 08:09 | **live 15:1x** |
|
||||
|---|---|---|
|
||||
| ap1 | `cap-wifi1` / `cap-wifi2` | `cap-wifi1` / `cap-wifi2` |
|
||||
| ap2 | `cap-wifi3` / `cap-wifi5` | **`cap-wifi5` / `cap-wifi6`** |
|
||||
| ap3 | `cap-wifi4` / `cap-wifi6` | **`cap-wifi3` / `cap-wifi4`** |
|
||||
|
||||
⇒ Die Karte verschiebt sich bei **jedem** CAP-Rejoin, nicht nur beim Re-Provisionieren. Bei fünf
|
||||
Reboots an einem Tag heißt das: **Interface-Namen in Logzeilen sind ohne Zeitstempel-nahen
|
||||
Karten-Snapshot nicht zuschreibbar.** Wer die Vormittagszeilen mit der jetzigen Karte liest, ordnet
|
||||
falsch zu. *(Strukturelle Antwort wäre ein stündlicher Karten-Snapshot ins Log — der Core ist
|
||||
**kein** `device-mode=home`, Scheduler ist dort erlaubt. Nicht gebaut, nur vorgeschlagen.)*
|
||||
|
||||
**3. Sticky-Verdacht, teilweise belegt.** Um 14:23 unbewegt am Schreibtisch **−72 dBm**, um 14:38 am
|
||||
selben Platz **−49 dBm**. Die Pegeldifferenz ist ein Faktum; **welcher** AP jeweils dahinterstand,
|
||||
ist wegen (2) nicht mehr rekonstruierbar. Über den Tag zeigt jedes Interface dieselbe Spannweite
|
||||
(−91…−47) — das Telefon hängt regelmäßig auf −85…−91, obwohl −47 möglich wäre.
|
||||
|
||||
**4. `docs/wifi-p750w-coverage-and-map.md` ist als Beleg unbrauchbar.** Die Datei ist vom
|
||||
**2026-07-02** — vor CAPsMAN-Cutover, vor ap2s Umzug nach oben, vor ap3. Ihre Aussage „Terrasse
|
||||
grenzwertig −76…−89 dBm" beschreibt ein Netz, das es nicht mehr gibt. Christophs Einschätzung
|
||||
(„seit ap2 nach oben hat die Terrasse faire Coverage") ist die jüngere Information. **In dieser
|
||||
Session hat die veraltete Zeile beinahe dazu geführt, den 13:16-Vorfall als „erwartbar" abzutun.**
|
||||
|
||||
**5. Erste ruhige Phase des Tages — unbewertet.** Zwischen dem Core-Reboot (14:37) und 15:12 steht
|
||||
**1** `reauthenticating` im Log, **keines vom iPhone**. 35 Minuten sind keine Aussage, und das
|
||||
iPhone lag zuletzt bei −49…−52 dBm. **Nicht als Erfolg verbuchen** — aber morgen früh gezielt
|
||||
prüfen, ob 7.24.1 auf dem Manager etwas verändert hat.
|
||||
|
||||
## Entscheidungslage für die nächste Session
|
||||
|
||||
Hebel 1 ist gescheitert. `sec-main` unterscheidet sich von den fünf ereignislosen SSIDs in **zwei**
|
||||
Attributen (bereits im Vorgänger korrigiert):
|
||||
|
||||
```
|
||||
sec-main authentication-types=wpa3-psk ft=yes ft-over-ds=no ← 93/93 Ereignisse
|
||||
sec-infra… authentication-types=wpa2-psk,wpa3-psk ft=no ← null Ereignisse
|
||||
```
|
||||
|
||||
| Option | Dafür | Dagegen |
|
||||
|---|---|---|
|
||||
| **Hebel 2 `ft=no`** | folgt der beschlossenen Reihenfolge, isoliert die FT-Achse sauber | bleibt WPA3-only; wenn das die Ursache ist, ändert sich nichts |
|
||||
| **`wpa2-psk,wpa3-psk`** | `no cached PMK` ist eine SAE/PMKSA-Meldung; iOS + WPA3-only + PMK-Caching ist ein bekanntes Problemfeld; bringt `main` exakt auf den Stand der ruhigen SSIDs | ändert das zweite Attribut, nicht das aus dem Plan |
|
||||
| **beides** | höchste Chance auf Ruhe | hinterher weiß niemand, welches gewirkt hat |
|
||||
|
||||
**Vor der Entscheidung zuerst prüfen:** ob 7.24.1 auf dem Manager das Verhalten schon verändert hat
|
||||
(Punkt 5). Ein Hebel, der auf ein bereits gelöstes Problem gezogen wird, verbrennt einen Messtag.
|
||||
|
||||
⚠️ Die Transaktion **`TP25-fund-e-ft-over-ds` bleibt offen** (Ablauf 2026-09-03), Compliance steht
|
||||
deshalb weiter absichtlich auf **134/135**. Rollback oder Commit ist eine bewusste Entscheidung,
|
||||
kein Aufräumen.
|
||||
|
||||
## Messrezept (unverändert gültig)
|
||||
|
||||
```bash
|
||||
ssh root@10.40.20.100 "pct exec 400 -- sh -c '
|
||||
grep -c reauthenticating /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log;
|
||||
grep -c \" caps,\" /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log'"
|
||||
```
|
||||
Erste Zahl = Fund A. Zweite Zahl = Reboots/Rejoins; steht sie über 0, **erst dort nachsehen**,
|
||||
bevor die erste Zahl gedeutet wird.
|
||||
|
||||
## Unverändert offen
|
||||
|
||||
1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — **Terrasse und Arbeitszimmer**, um die
|
||||
Sticky-Frage aus Punkt 3 zu entscheiden. `ap-map` dabei neu einfrieren.
|
||||
2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt; fehlende `MCP_MIKROMCP_*_PASS`).
|
||||
3. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste**, `tx-power` vorher messen).
|
||||
4. Karten-Snapshot ins Log automatisieren (Vorschlag aus Punkt 2, nicht gebaut).
|
||||
@@ -89,9 +89,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
|
||||
Vor-Ort-Session** (§2/§3: `container.npk`, `device-mode`, Container) und danach Flip + Abbau.
|
||||
- 🆕 **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`.
|
||||
|
||||
- **Fünf MikroTik, alle auf RouterOS `7.24.1`** (User-Upgrade 2026-08-31, live gegengelesen;
|
||||
RouterBOOT jeweils = `upgrade-firmware` = `7.24.1`). Neu dabei **`ap3`** (cAP ax `cAPGi-5HaxD2HaxD`,
|
||||
**`10.40.99.13`**, Uplink core `ether21`).
|
||||
- **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. RouterBOOT jeweils = `upgrade-firmware` = `7.24.1`, live gegengelesen).
|
||||
Vorher: vier auf 7.24 (08-17), nur ap3 auf 7.24.1. Neu in der Flotte **`ap3`**
|
||||
(cAP ax `cAPGi-5HaxD2HaxD`, **`10.40.99.13`**, Uplink core `ether21`).
|
||||
✅ **Folge für TP16.3:** die versionsgebundene `container.npk` ist damit **eine** Datei für alle drei
|
||||
APs (alle `arm64`) — die Zwei-Dateien-Regel vom 08-30 war rein versionsbedingt und ist erledigt.
|
||||
*(Hier stand bis 08-29 „Alle vier MikroTik … 7.24" — durch ap3 und das Upgrade zweifach überholt.)*
|
||||
@@ -112,7 +114,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
|
||||
@@ -157,16 +159,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;
|
||||
@@ -1820,8 +1833,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
|
||||
|
||||
@@ -36,6 +36,9 @@ sie stehen nicht im Soll, weil Runbook §3.4 Direkt-Writes vorschreibt für Feat
|
||||
Golden-Config-Kontrolle stehen.
|
||||
|
||||
Der saubere Weg ist, sie ins **Soll** zu heben (AP-Template bzw. ConfigContext `ap-common`).
|
||||
🔑 **Bewusst KEINE Transaktion:** `gc-transaktion.py` ist für **befristete Versuche** da (so wie
|
||||
`TP25-fund-e-ft-over-ds`). Das `veth`/`masquerade` soll **dauerhaft** gelten — Dauerzustand gehört
|
||||
ins Template, nicht in eine Transaktion mit Ablaufdatum.
|
||||
🔴 **Kein Re-Baseline** (macht die Drift-Erkennung wertlos), **kein Rückbau** (killt die Tunnel).
|
||||
⚠️ Dabei mitentscheiden, ob `/interface veth` überhaupt erfasst sein soll — dafür existiert heute
|
||||
keine ComplianceRule, deshalb erzeugt `veth` auch keine Drift.
|
||||
@@ -43,8 +46,14 @@ keine ComplianceRule, deshalb erzeugt `veth` auch keine Drift.
|
||||
Mit ungeklärter Drift in den Produktivpfad zu gehen ist die eine Sache, die diese Session
|
||||
**nicht** tun sollte. Christoph entscheidet, nicht die Session.
|
||||
|
||||
*(Die siebte Drift, `crs326-core` / `wifi-security` / `ft-over-ds`, ist die bekannte aus dem
|
||||
7.24.1-Upgrade und gehört weiterhin nicht in diese Session.)*
|
||||
🔴 **Die siebte Drift ist KEINE Drift im Sinne eines Versehens:** `crs326-core` / `wifi-security`
|
||||
(`ft-over-ds=no`) ist **TP25 Fund E, Hebel 1** — am 2026-08-31 um 08:09 bewusst gesetzt und als
|
||||
**offene Transaktion `TP25-fund-e-ft-over-ds`** geführt (Scope `wifi-security`, Ablauf 2026-09-03).
|
||||
Sie gehört einer anderen, laufenden Session; **grün machen würde deren Versuch unsichtbar machen.**
|
||||
⚠️ **Merkregel:** vor jeder Drift-Bewertung `python3 nautobot/gc-transaktion.py status` lesen.
|
||||
Drift aus einem laufenden Versuch sieht identisch aus wie ein Versehen — genau dafür gibt es das
|
||||
Werkzeug. (Diese Zeile behauptete zuerst, die Drift käme vom 7.24.1-Upgrade. Falsch: der Core wurde
|
||||
erst um 14:36 gehoben, sechseinhalb Stunden nach dem Hebel.)*
|
||||
|
||||
## REIHENFOLGE
|
||||
|
||||
@@ -89,8 +98,8 @@ zuletzt. Nach **jedem** Namen die Abnahme aus §5.3, erst dann der nächste.
|
||||
|
||||
1. **Rotation zweier Nautobot-Tokens** (`NAUTOBOT_SUPERUSER_API_TOKEN`, `NAUTOBOT_GITEA_TOKEN`) —
|
||||
in der Vorsession ins Transkript geraten, als verbrannt zu behandeln. Gehört zu **TP30**.
|
||||
2. **`crs326-core` / `wifi-security` / `ft-over-ds`** — bekannte Drift, braucht eigenen Entscheid
|
||||
plus CAP-Re-Provisionierung.
|
||||
2. **`crs326-core` / `wifi-security` / `ft-over-ds`** — offene Transaktion `TP25-fund-e-ft-over-ds`
|
||||
einer laufenden TP25-Session. **Nicht anfassen, nicht grün machen**, Ablauf 2026-09-03.
|
||||
3. **`mcp/mikromcp/config/routers.yaml`** meldet `rosVersion: "7.24"` für alle fünf, live ist
|
||||
`7.24.1` — kosmetisch, gehört auf `main`.
|
||||
4. **§6 Abbau** (sechs Container, drei Alttunnel) — frühestens 7 Tage nach dem Flip.
|
||||
|
||||
Reference in New Issue
Block a user