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>
This commit is contained in:
140
docs/handoff-20260831-fund-e-hebel1-gezogen.md
Normal file
140
docs/handoff-20260831-fund-e-hebel1-gezogen.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user