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>

nautobot/gc-transaktion.py

@@ -123,10 +123,14 @@ def geheim(device):
 def export(device):
     """/export vom Geraet holen — der Snapshot, gegen den spaeter zurueckgebaut wird."""
     ip = IPS.get(device) or sys.exit("Keine IP fuer %r." % device)
-    p = subprocess.run(["sshpass", "-p", geheim(device), "ssh",
+    # 🔴 `sshpass -p` schreibt das Passwort in argv, wo es in `ps` und jedem
+    #    argv-Trace steht — genau so ist am 2026-08-22 das Core-Passwort in ein
+    #    Transkript geraten. `-e` haelt es in der Umgebung des Kindprozesses.
+    umgebung = dict(os.environ, SSHPASS=geheim(device))
+    p = subprocess.run(["sshpass", "-e", "ssh",
                         "-o", "StrictHostKeyChecking=no", "-o", "ConnectTimeout=10",
                         "admin@" + ip, "/export"],
-                       capture_output=True, text=True, timeout=120)
+                       capture_output=True, text=True, timeout=120, env=umgebung)
     if p.returncode != 0:
         sys.exit("Export fehlgeschlagen (rc=%d). %s" % (p.returncode, p.stderr[:200]))
     return p.stdout