TP6 gemessen: Fall B, aber nicht hoerbar -- und der laute Befund liegt bei TP25

Die TP6-Praemisse ist ausgefuehrt: drei Messreihen von einem kabelgebundenen
Client in VLAN10, zwei davon mit laufendem Telegram-Videocall an zwei Orten.

Ergebnis (Runbook §5): unter Dauer-Upload steigt die Latenz von 13 auf 40--60 ms,
im Download auf 36--41 ms. Das sind +28 bis +47 ms und damit ueber der Schwelle
von 30 ms, die §3 VOR der Messung festgelegt hat -- formal Fall B, CAKE ist
begruendet. Die Einschraenkung gehoert zur Zahl: durch alle sechs Lastphasen lief
ein Videocall, und es wurde kein einziger Problem-Button gedrueckt. Messbar ja,
wahrnehmbar nein. waveform sagt zeitgleich Grade A -- kein Widerspruch, sondern
ein kuerzerer Test, dessen Upload-Verteilung zweigipflig ist (25. Perzentil
14,5 ms, 75. Perzentil 47,5 ms).

Erstmals dokumentiert: die tatsaechliche Linerate. Upload 9,6 Mbit, Download
54,6 Mbit. Die im Repo kolportierten "~10 Mbit" galten immer nur dem Upload.

Der lautere Befund ist ein Nebenprodukt: der Core-Sampler hat 2,5 Stunden lang
das iPhone mitgeschrieben. Sticky Client (ein Weg durchs ganze Haus, dreimal
direkt an ap1 vorbei, eine einzige Uebergabe -- und die erst oben bei -73 dBm)
und Band-Ping-Pong (zwoelf Wechsel in neun Minuten am selben Ort). Je Wechsel bis
zu 4 s ohne Durchsatz -- als Obergrenze notiert, denn die Zaehler starten nach
einer Neuanmeldung bei null; der saubere Test per ping auf das Telefon steht aus.
Das passiert TROTZ aktivem 802.11k/v und FT, live geprueft: damit ist die
Merkregel ref_ft_is_not_roaming historisch. Der Bandabstand von 8--10 dB ist
dabei normale Physik; das Problem ist, dass 5 GHz an den Telefonier-Orten bei
-75 bis -80 dBm landet.

Zwei Messfehler bleiben dokumentiert, weil sie die Methode betreffen und beide
denselben Typ haben -- die Anzeige war gruen, die Wirkung fehlte:
speed.cloudflare.com/__down antwortet ohne User-Agent mit 403 und einem Byte
(saubere Ping-Reihe ueber tote Flows), und ein Call lief 5,5 Minuten ohne
Treiber (Marker geschrieben, nichts gemessen).

Status nachgezogen -- Header inklusive: TP6 von "Praemisse pruefen" auf
"gemessen, Fall B, nachrangig", TP25 auf kritischen Pfad. Rohdaten liegen unter
docs/messdaten/tp6-20260820/, damit die Zahlen nachpruefbar bleiben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/tp25-wlan-roaming-messung-20260820.md

@@ -0,0 +1,155 @@
+# TP25 — Roaming- und Bandmessung am laufenden Videocall (2026-08-20/21)
+
+> **Nebenprodukt der TP6-Messung, aber der lautere Befund.** Während der Bufferbloat-Messreihen
+> (`tp6-praemisse-messrunbook.md` §5) lief ein Core-Sampler mit, der im 2-Sekunden-Takt die
+> Registration-Table-Werte von Christophs iPhone mitgeschrieben hat: AP/Band, Signal, PHY-Rate und
+> Durchsatz. Über zweieinhalb Stunden, mit Ortswechseln, teils mit laufendem Telegram-Videocall.
+>
+> **Kein Netz-Eingriff.** Alles hier ist gemessen, nichts konfiguriert.
+
+**Client:** iPhone, MAC `F2:62:4C:E1:AF:09`, statische Lease `10.40.10.196`, SSID `dirtyvader-main`.
+**Werkzeug:** `docs/tp6-monitor-core.sh` (liest am **Manager** — unter CAPsMAN sind die AP-Tabellen leer).
+**Rohdaten:** `docs/messdaten/tp6-20260820/`.
+
+---
+
+## 1. Ausgangslage: Funkparameter sind NICHT die Baustelle
+
+Live am Core geprüft (2026-08-21), damit niemand das nochmal recherchiert:
+
+| | |
+|---|---|
+| Fast Transition | `security.ft=yes`, `ft-over-ds=yes` auf allen vier `cfg-main-*` |
+| **802.11k (rrm)** | **aktiv** — `steering=st-main`, `neighbor-group=bf-main`, `rrm=yes` |
+| **802.11v (wnm)** | **aktiv** — `wnm=yes`, ebenfalls über `st-main` |
+| Kanäle 5 GHz | ap1 **5180** (ch36), ap2 **5220** (ch44), Breite **20/40 MHz** |
+| Kanäle 2,4 GHz | ap1 **2412** (ch1), ap2 **2462** (ch11), Breite 20 MHz |
+| TX-Power | **nicht explizit gesetzt** → Länder-Maximum (`country=Austria`) |
+
+📌 **Die Merkregel `ref_ft_is_not_roaming` („11k/v fehlten") ist damit historisch** — sie sind seit der
+CAPsMAN-Rückkehr (TP28, 2026-08-17) aktiv. Was unten gemessen wird, passiert **trotz** 11k/v/FT.
+
+---
+
+## 2. Befund A — der Bandabstand ist normal, das absolute 5-GHz-Niveau ist es nicht
+
+Am selben Ort, innerhalb weniger Sekunden gemessen (das Gerät lag still):
+
+| Band | Signal |
+|---|---|
+| ap2 / **2,4 GHz** | **−67 bis −72 dBm** |
+| ap2 / **5 GHz** | **−75 bis −80 dBm** |
+
+**Der Abstand von 8–10 dB ist unauffällig.** Allein die Freiraumdämpfung erklärt bei 2412 vs. 5220 MHz
+schon **6,7 dB** (20·log₁₀(5220/2412)); Wände und Decken dämpfen bei 5 GHz zusätzlich stärker. Ein
+Delta von 8–10 dB liegt am oberen Rand des Erwartbaren, nicht jenseits davon. Verstärkt wird es **nicht**
+durch die Konfiguration: es ist keine TX-Leistung reduziert, und im 5-GHz-Band ch36–48 erlaubt ETSI
+indoor sogar mehr EIRP als auf 2,4 GHz.
+
+🔴 **Das eigentliche Problem ist nicht der Abstand, sondern der Absolutwert:** an den Orten, an denen
+tatsächlich telefoniert wird, landet 5 GHz bei **−75 bis −80 dBm**. Das ist die Zone, in der ein Client
+anfängt zu zweifeln — und genau das tut er dann auch (Befund C).
+
+---
+
+## 3. Befund B — Sticky Client: ein Weg durchs ganze Haus, eine einzige Übergabe
+
+Aufgezeichnet am 2026-08-20, 23:33–23:41, mit laufendem Videocall. Weg: **Küche (UG) → Kinderzimmer →
+Schlafzimmer → Treppe → Terrasse (OG)**, dabei **unmittelbar an ap1 vorbei** (Boden Diele UG/Technik UG).
+
+```
+23:33–23:37  ap1/5GHz  −70…−74 dBm             Küche, stabil
+23:37:50     ap1/5GHz  −46 dBm   229 Mbps      direkt an ap1 vorbei (1. Mal)
+23:38:22     ap1/5GHz  −43 dBm   275 Mbps      an ap1 vorbei (2. Mal)
+23:39:47     ap1/5GHz  −51 dBm   275 Mbps      an ap1 vorbei (3. Mal)
+23:40:05     ap1/5GHz  −73 dBm                 Treppe hoch
+23:40:07     ap2/5GHz  ——        0,00 Mbit     ⟵ Übergabe
+23:40:11     ap2/5GHz  −74 dBm   103 Mbps      wieder Durchsatz
+23:40:46     ap2/5GHz  −77 dBm    68 Mbps      Terrasse
+```
+
+**Das Telefon hat auf dem gesamten Weg an ap1 festgehalten** und erst oben gewechselt, bei −73 dBm.
+Zwischendurch stand es dreimal fast unter ap1 (−43 dBm) — die Signalspitzen sind die Wegmarken.
+Eine einzige Übergabe auf dem ganzen Weg ist **wenig**, nicht viel: der Client bleibt hängen, bis es
+fast nicht mehr geht.
+
+---
+
+## 4. Befund C — Band-Ping-Pong: zwölf Wechsel in neun Minuten, ohne Ortswechsel
+
+2026-08-21, 00:03–00:12, **ohne** Call, Gerät im Wesentlichen am selben Ort:
+
+```
+00:03:28  ap2/5GHz   −69      00:06:08  ap2/5GHz   −76
+00:03:56  ap2/2,4GHz −72      00:06:46  ap2/2,4GHz −68
+00:04:18  ap2/5GHz   −78      00:07:55  ap2/5GHz   −78
+00:04:45  ap2/2,4GHz −69      00:08:03  ap2/2,4GHz −71
+```
+
+**Immer derselbe AP, nur das Band wechselt** — 5 GHz ist mit −76…−80 grenzwertig, 2,4 GHz sieht mit
+−68…−72 besser aus, danach dreht sich die Bewertung wieder. Klassisches Ping-Pong am Rand der
+Reichweite. Dieselbe Signatur zeigte sich am zweiten Messort direkt nach dem Auflegen: **acht Wechsel
+in vier Minuten** (23:59:11 → 00:03:28).
+
+Ohne Call ist das folgenlos. **Mit Call wäre es alle 40 Sekunden eine Unterbrechung** — und damit die
+bessere Erklärung für „plötzlich nicht mehr lippensynchron" als alles, was in `call-quality-diagnosis.md`
+bisher an lokalen Ursachen geprüft wurde.
+
+---
+
+## 5. Was die Lücke kostet — und was daran noch ungemessen ist
+
+Bei **jedem** beobachteten Wechsel steht in den Zählern des Managers für **rund 4 Sekunden** kein
+Durchsatz, danach folgen ~10 Sekunden mit halber PHY-Rate.
+
+⚠️ **Diese 4 Sekunden sind eine Obergrenze, kein Beweis.** Nach einer Neuanmeldung beginnen die Zähler
+der Registration-Table bei null; ein Teil der Lücke kann Zähler-Artefakt statt echter Funkstille sein.
+Auch der Rücksprung von `uptime` auf `00:00:00` beweist **nicht**, dass keine Fast Transition stattfand —
+auch eine FT erzeugt am Zielradio einen neuen Eintrag.
+
+**Der saubere Test, der das entscheidet** (eine Zeile, read-only, beim nächsten Spaziergang mitlaufen
+lassen — vom Core, damit der Weg kurz ist):
+
+```bash
+ping -i 0.2 10.40.10.196
+```
+
+Ein Wechsel zeigt sich dann als **echter Paketverlust über N×200 ms**. Fällt dabei nichts aus, ist die
+Übergabe schnell und die 4 Sekunden waren Buchhaltung. Fallen 20 Pakete aus, ist es real — und dann ist
+es die Ursache für die Aussetzer im Call.
+
+---
+
+## 6. Handlungsoptionen — in der Reihenfolge, in der sie Sinn ergeben
+
+> **Randbedingung des Users (2026-08-17, gilt weiter):** *„ich weigere mich einen anderen access point zu
+> kaufen solange ich nicht das gefühl habe, wir haben alles aus dem ap rausgeholt."* Deshalb steht neue
+> Hardware unten, nicht oben.
+
+1. **Erst die Lücke messen** (§5). Alles Weitere hängt davon ab, ob die Übergabe 200 ms oder 4 s kostet.
+2. **5 GHz auf 20 MHz Breite festnageln** — aktuell `20/40mhz`. Halbe Bandbreite = **+3 dB** effektives
+   Link-Budget, und ein Videocall braucht 1,2 Mbit, keine 200. Billigste Reichweitenverbesserung, die
+   es gibt, ohne Nebenwirkung auf andere Clients. Weg: GC-Template, nicht direkt.
+3. **Fund E aus TP25 endlich umsetzen: `access-list` mit `signal-range`-Boden am Manager.** Genau dafür
+   ist er da — einen Client, der unter z. B. −78 dBm fällt, nicht mehr assoziieren lassen, damit er sich
+   den besseren AP sucht statt zu kleben. ⚠️ **Mit Bedacht:** ein zu hoher Boden sperrt Geräte komplett
+   aus. Erst Signalkarte, dann Schwelle.
+4. **2,4-GHz-Leistung senken: NICHT als erster Schritt.** Es ist der klassische Reflex („Band Steering
+   durch Verkrüppeln"), aber hier hängen **rund 20 IoT-Geräte** auf `dirtyvader-iot` im 2,4-GHz-Band,
+   viele davon bei −70 bis −80 dBm. Man würde ein funktionierendes Netz beschädigen, um ein Symptom auf
+   einem anderen zu verschieben. Wenn überhaupt, dann **nach** 1–3 und nur um wenige dB.
+5. **Dritter AP** — die einzige Maßnahme, die −78 dBm wirklich beseitigt, statt sie zu verwalten.
+   Erst wenn 1–3 durch sind, ist die Randbedingung oben erfüllt.
+
+---
+
+## 7. Was das für die Call-Qualität bedeutet
+
+`call-quality-diagnosis.md` stuft Roaming als **Nebenfaktor** ein — begründet mit Kontrollexperiment 1:
+Christophs **nationale** Videocalls waren auf derselben WLAN-Infrastruktur gut. Diese Logik hält, und
+diese Messung widerlegt sie nicht.
+
+**Was sie hinzufügt:** einen konkreten, gemessenen lokalen Mechanismus für die *plötzlichen* Einbrüche —
+Sekundenlöcher durch Neuanmeldung —, der neben der ratengebundenen Hypothese existiert und sie nicht
+ersetzt. Der Lippen-Versatz vom 2026-08-20 (~22:04:37 Neuanmeldung, 22:05:32 Call beendet) ist der
+erste Fall, für den beide Seiten der Zeitachse vorliegen.