bf-infra/docs/handoff-20260831-fund-e-hebel1-gezogen.md

Handoff 2026-08-31 — TP25 Fund E: Hebel 1 ist gezogen, die Uhr läuft

Vorgänger: 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 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

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:

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