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>
8.1 KiB
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):
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.
- Erst die Lücke messen (§5). Alles Weitere hängt davon ab, ob die Übergabe 200 ms oder 4 s kostet.
- 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. - Fund E aus TP25 endlich umsetzen:
access-listmitsignal-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. - 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-iotim 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. - 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.