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

> Vorgänger: [`handoff-20260831-fund-e-hebel1-gezogen.md`](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)

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