Files
bf-infra/docs/tp25-wlan-roaming-messung-20260820.md
Christoph Emsenhuber cf44ce6a1e 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>
2026-08-21 00:31:13 +02:00

8.1 KiB
Raw Blame History

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.

  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.