bf-infra/docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md

Handoff 2026-08-31 nachmittags — TP27 durchgezogen, Hebel 1 gescheitert, Fund B entwarnt

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

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).