Files
bf-infra/docs/handoff-20260831-fund-e-hebel1-gezogen.md
Christoph Emsenhuber a0a650eb48 TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main, Messung laeuft
Ein Hebel, sonst nichts. 2026-08-31 08:09 am Manager crs326-core:
  /interface wifi security set [find name="sec-main"] ft-over-ds=no
  /interface wifi capsman remote-cap provision [find]
ft=yes bleibt -- FT laeuft weiter over-the-air, nur nicht mehr over-the-DS.
Nimmt exakt die Aenderung vom 2026-08-17 zurueck.

Abnahme (Lease, nicht Registration-Table):
- Manager, alle vier aktiven Master-VAPs cap-wifi3/4/5/6: ft=true ft-over-ds=false
- alle 3 CAPs state=Ok, alle VAPs running=yes AM CAP gelesen
- iPhone nach 71 s zurueck auf dirtyvader-main, frische Lease 10.40.10.196,
  auth-type=ft-wpa3-psk, -54 dBm; 30 Clients gesamt zurueck
- Log 08:13:20 zeigt sauberes "roamed to" zwischen zwei APs -> Roaming intakt
- Geraete-Backup vorher: pre-tp25-funde-ftoverds.backup

Governance: Transaktion TP25-fund-e-ft-over-ds OFFEN (Scope wifi-security,
Ablauf 2026-09-03). Compliance steht deshalb ABSICHTLICH auf 134/135; der Diff
ist exakt ft-over-ds=yes->no, kein Kollateral-Drift durch die Re-Provisionierung.
Das GC-Template wird erst beim COMMIT nachgezogen -- vorher gruen machen wuerde
den laufenden Versuch unsichtbar machen, und gc-transaktion.py verweigert den
Commit ohnehin, solange der Scope driftet. 135/135 kommt nach der Messung zurueck.

Messstand nach 25 min: weiter 93, letzter reauthenticating 07:34:43 (vor dem
Eingriff). Logging nachweislich lebendig (593 wireless-Zeilen heute, beide SSIDs).
Noch kein Ergebnis, nur ein sauberer Schnitt.

Drei Funde:
- cap-wifiN-Karte hat sich beim Re-Provisionieren VERSCHOBEN: ap2 war 1/2 ->
  jetzt 3/5, ap3 war 5/6 -> jetzt 4/6, ap1 hat 1/2 bekommen. Wer die 07:xx-Zeilen
  gegen die neuen liest, ordnet dem falschen AP zu.
- Korrektur am Vormittagsbefund: main unterscheidet sich in ZWEI Attributen, nicht
  einem -- es ist auch die einzige SSID ohne wpa2-psk. Die Kontrollgruppe trennt FT
  und WPA3-only nicht. Wenn Hebel 1 und 2 beide nichts bewegen, ist
  authentication-types der naechste Kandidat, NICHT signal-range.
- gc-transaktion.py rief sshpass -p auf (Passwort in argv, Klasse vom 2026-08-22).
  Auf SSHPASS-Env + -e umgestellt, weil das Skript laufen musste. Fuenf weitere
  Dateien unter routeros/ haben dasselbe Muster und sind bewusst NICHT angefasst
  (Stop-Bedingung; gehoert zu TP30). Entwarnung: /export auf 7.24 gibt Passphrasen
  gar nicht aus (live geprueft), die Transaktionsakte im Git ist sauber.

Nebenbei: .gitignore hatte docs/nas-vlan20/stacks/ MIT Schraegstrich -- im Worktree
liegt dort ein Symlink auf den Haupt-Checkout, der war damit nicht ignoriert.

Doku an allen drei Stellen nachgezogen (Quick-Index, TP25-Abschnitt, Ist-Stand-Block)
plus CLAUDE.md-Pflichtlektuere und neuer Handoff mit Entscheidungstabelle fuer 09-01.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 08:19:31 +02:00

141 lines
7.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Handoff 2026-08-31 — TP25 Fund E: Hebel 1 ist gezogen, die Uhr läuft
> Vorgänger: [`handoff-20260831-wlan-fund-e.md`](handoff-20260831-wlan-fund-e.md) (Befund + Messrezept).
> **Dieses Dokument ist der Stand danach.** Es gibt genau eine offene Aufgabe: **messen und entscheiden.**
## Was am 2026-08-31 um 08:09 passiert ist
**Eine** Änderung, sonst nichts:
```
/interface wifi security set [find name="sec-main"] ft-over-ds=no # vorher: yes
/interface wifi capsman remote-cap provision [find]
```
`ft=yes` bleibt — Fast Transition läuft weiter **over-the-air**, nur nicht mehr **over-the-DS**. Das
nimmt exakt die Änderung vom 2026-08-17 zurück, mehr nicht. **Kein weiterer Funk-Parameter ist
angefasst worden** (Stop-Bedingung: wer zwei Hebel zieht, weiß hinterher nichts).
## Abnahme — was tatsächlich geprüft wurde
| Prüfung | Ergebnis |
|---|---|
| Wirkt der Hebel? **am Manager, alle Master-VAPs** | `cap-wifi3/4/5/6` → `ft=true ft-over-ds=false`. `cap-wifi1/2` (= ap1) leer, weil ap1 funkstill ist. |
| CAPs zurück? | alle drei `state=Ok` |
| VAPs laufen? **am CAP gelesen**, nicht am Manager | ap2 und ap3: alle 9 Interfaces `running=yes` |
| **Frische DHCP-Lease** (die vorgeschriebene Abnahme) | iPhone `F2:62:4C:E1:AF:09` nach 71 s wieder auf `dirtyvader-main`, `10.40.10.196`, **`auth-type=ft-wpa3-psk`**, −54 dBm |
| Clients gesamt | 30 zurück |
| Roaming funktioniert noch? | ja — Log zeigt um 08:13:20 ein sauberes `roamed to` zwischen zwei APs auf `main` |
| Compliance | **134/135**, Diff **exakt** `ft-over-ds=yes → no`. **Kein Kollateral-Drift.** |
Geräte-Backup vor dem Eingriff: `pre-tp25-funde-ftoverds.backup` auf dem Core (08:07:58).
## 🔴 Warum Compliance auf 134/135 steht und das RICHTIG ist
Die Transaktion **`TP25-fund-e-ft-over-ds`** ist **offen** (Scope `wifi-security`, Ablauf
**2026-09-03**). `gc-transaktion.py status` weist den einen Drift als **erwartet** aus — genau dafür
gibt es das Werkzeug.
**Das Template wird bewusst NICHT vorher nachgezogen.** Wer es jetzt grün macht, macht den laufenden
Versuch unsichtbar, und `status` kann ihn nicht mehr von einem Versehen unterscheiden. `gc-transaktion.py`
erzwingt die richtige Reihenfolge ohnehin: es verweigert den Commit, solange der Scope driftet.
**135/135 kommt beim Commit zurück** — nach der Messung, nicht davor.
## 🔴 Die `cap-wifiN`-Karte hat sich beim Re-Provisionieren VERSCHOBEN
Wer die Logs vom 31.08. auswertet und das übersieht, ordnet Ereignisse dem falschen AP zu:
| | vor 08:09 (Logzeilen 07:xx) | ab 08:09 |
|---|---|---|
| ap1 (funkstill) | — | `cap-wifi1` / `cap-wifi2` |
| ap2 | `cap-wifi1` / `cap-wifi2` | `cap-wifi3` / `cap-wifi5` |
| ap3 | `cap-wifi5` / `cap-wifi6` | `cap-wifi4` / `cap-wifi6` |
Gelesen mit `/interface wifi radio print` am Manager. Das ist dieselbe Instabilität, die
[`tp25-walk-messung.sh`](tp25-walk-messung.sh) als `ap-map.txt` einfriert — hier von Hand.
## ⚠️ Korrektur am Befund vom Vormittag
Der Vorgänger-Handoff sagt, `main` unterscheide sich von den anderen fünf SSIDs in **genau einem**
Attribut. **Live nachgelesen sind es zwei:**
```
sec-main authentication-types=wpa3-psk ft=yes ft-over-ds=yes
sec-infra … authentication-types=wpa2-psk,wpa3-psk ft=no
```
`sec-main` ist **auch die einzige SSID ohne `wpa2-psk`**. Die Kontrollgruppe trennt FT und WPA3-only
also **nicht** voneinander. Das ändert die Hebelreihenfolge nicht — die Hypothese nennt gerade die
Kombination WPA3+FT — aber es ändert den Plan B:
⇒ **Wenn Hebel 1 und Hebel 2 (`ft=no`) beide nichts bewegen, ist der nächste Kandidat
`authentication-types=wpa2-psk,wpa3-psk` auf `sec-main` — NICHT `signal-range`.**
## Die einzige offene Aufgabe: messen
```bash
ssh root@10.40.20.100 "pct exec 400 -- sh -c 'cat /opt/tp5-syslog/log/10.40.20.1/2026-0*-*.log |
grep reauthenticating | grep -oE \"([0-9A-F]{2}:){5}[0-9A-F]{2}\" | sort | uniq -c'"
```
**Baseline: 93**, alle vom iPhone `F2:62:4C:E1:AF:09`, alle auf `dirtyvader-main`.
Davon **79 am 31.08., sämtlich in Stunde 07**, der letzte um **07:34:43** — also **vor** dem Eingriff.
Zwischen 08:00 und 08:15 kein einziges. **Das ist noch kein Ergebnis, nur der saubere Schnitt.**
Ein Gegencheck gehört dazu — er beweist, dass nicht einfach das Logging kaputt ist:
```bash
ssh root@10.40.20.100 "pct exec 400 -- sh -c '
grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | wc -l;
grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | grep -oE \"\\(dirtyvader-[a-z]+\\)\" | sort | uniq -c'"
```
### Die Entscheidung am 2026-09-01
| Messung | Schluss | Nächster Schritt |
|---|---|---|
| iPhone-`reauthenticating` **~0**, andere SSIDs unverändert | Hebel 1 hat gegriffen | Template `mikrotik_routeros.j2` Z. 220 auf `ft-over-ds=no` ziehen → `gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds` → Compliance zurück auf 135/135 |
| Zahl **unverändert** | Hebel 1 hat **nicht** gegriffen | Rollback ODER stehen lassen und **Hebel 2 `ft=no`** als eigene Transaktion. Nicht beides gleichzeitig. |
| Zahl runter, aber neue Ereignisse auf anderen SSIDs | Nebenwirkung | Rollback, dann neu bewerten |
Rollback-Weg (der Snapshot liegt bereit):
`python3 nautobot/gc-transaktion.py rollback --change-id TP25-fund-e-ft-over-ds`
— erzeugt einen **Vorschlag**, der gelesen werden will, und pusht bewusst nicht selbst.
## 🔧 Nebenbefund: `sshpass -p` in sechs Skripten
`nautobot/gc-transaktion.py` rief `sshpass -p <PW>` auf — das schreibt das Passwort in `argv`, wo es
in `ps` und jedem argv-Trace steht. Das ist die Klasse, an der am 2026-08-22 das Core-Passwort
verbrannt ist, und CLAUDE.md verbietet sie ausdrücklich. **In `gc-transaktion.py` behoben**
(`SSHPASS`-Env + `-e`), weil das Skript für diese Aufgabe laufen musste.
🔴 **Fünf weitere Dateien haben dasselbe Muster und sind NICHT angefasst** (Stop-Bedingung —
gehört in eine eigene Runde, sinnvollerweise mit TP30):
```
routeros/import-core-rsc.py Z. 50, 74
routeros/apply-core-cutover-l3.py Z. 29, 55
routeros/backup-core.py Z. 29, 41
routeros/restore-core.py Z. 30, 42
routeros/backup-ap1.py Z. 29, 41
```
**Entwarnung zum Snapshot:** `/export` auf ROS 7.24 gibt WLAN-Passphrasen **gar nicht** aus
(0 Vorkommen im Vollexport, live geprüft). Die Transaktionsakte im Git ist sauber.
## 🔧 Zweiter Nebenbefund: Worktrees können `gc-*.py` nicht ohne Handgriff ausführen
`docs/nas-vlan20/stacks/210-nautobot.yml` ist gitignored und existiert deshalb **nur im
Haupt-Checkout**. In einem Worktree scheitern `gc-transaktion.py` und `gc-configplan.py` am
Nautobot-Token. Behelf in dieser Session war ein Symlink auf den Haupt-Checkout — **der gehört nicht
committet**. Dauerhafte Antwort wäre `NAUTOBOT_TOKEN` aus `~/.secrets/exports.zsh` (gc-configplan
liest die Variable bereits; gc-transaktion liest nur die Stack-Datei).
## Unverändert offen (nicht Teil dieser Session)
1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — ⚠️ **die `ap-map` neu einfrieren**, s.o.
2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt; fehlende `MCP_MIKROMCP_*_PASS` in `exports.zsh`)
3. MikroMCP-Neustart (Registry inkl. ap3 wird nur beim Start gelesen)
4. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste** statt Einzelwert, `tx-power` vorher messen)
5. Versions-Angleichung 7.24 → 7.24.1