Files
bf-infra/docs/tp25-wlan-roaming-messung-20260820.md
Christoph Emsenhuber 6cd41d5e9b TP25: Gehweg-Messung -- was eine WLAN-Uebergabe wirklich kostet
Die "~4 Sekunden je Wechsel" aus der Nachtmessung waren als Obergrenze markiert,
und die Vorsicht war berechtigt: 5 Pings/s auf das Telefon zeigen bei -48 bis
-55 dBm Uebergabekosten von 0 bis 2,6 s, meist unter einer halben Sekunde. Fast
Transition funktioniert. Der Zaehlerstand nach einer Neuanmeldung hatte die
Luecke vorgetaeuscht.

Der wahre Befund ist schlimmer und liegt woanders: bei -69 bis -77 dBm ist das
Telefon 6 bis 45 s nicht erreichbar, zweimal ueber 20 s am Stueck. Die Trennlinie
laeuft sauber entlang der Signalstaerke, nicht entlang der Wechsel -- es ist kein
Roaming-Problem, es ist ein Dead Spot.

Ehrlich dazu: ueber den ganzen Weg gingen 44 % der Pings verloren, und das ist
nicht alles Funk -- ein iPhone mit gesperrtem Display beantwortet ICMP verzoegert
oder gar nicht (RTT-Median 3,7 ms, Maximum 8,2 s). Power-Save haengt aber am
Display, nicht am Ort; dass alle langen Luecken in der schwachen Zone liegen und
alle kurzen in der starken, erklaert es nicht. Fuer eine exakte Zahl braucht es
ein waches Telefon.

tp6-monitor-core.sh bekommt eine Reconnect-Schleife: die SSH-Sitzung ist mitten
in der Messung weggebrochen und die Funkdaten endeten 2,5 Minuten vor dem
Ping-Mitschnitt -- ausgerechnet im interessanten Teil.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 15:15:56 +02:00

10 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 — GEMESSEN am 2026-08-21

Methode: docs/tp25-walk-messung.sh — 5 Pings/s auf das Telefon (10.40.10.196) plus Funk-Sampler im 1-s-Takt, während Christoph den Weg abgeht, den er beim Telefonieren wirklich geht. Kein Call, keine Last. 22 Minuten, 6.590 Pings, 10 AP-/Bandwechsel. Rohdaten: docs/messdaten/tp25-gehweg-20260821/.

5.1 Das Ergebnis trennt sauber nach Signalstärke

Zeit Wechsel Signal echter Paketverlust
14:52:27 ap2/5 → ap1/5 −48 dBm 2,6 s
14:53:57 ap1/5 → ap2/5 −51 dBm keine messbare Lücke
15:03:45 ap2/5 → ap1/5 −55 dBm 0,2 s
15:06:59 ap1/5 → ap2/5 −53 dBm 2,0 s
15:07:47 ap2/2,4 → ap2/5 −76 dBm 0,4 s
15:07:07 ap2/5 → ap2/2,4 −76 dBm 6,4 s
15:08:17 ap2/5 → ap2/2,4 −69 dBm 20,0 s
15:08:30/33 ap2 5↔2,4 (zweimal) −77 dBm 44,6 s
15:09:28 ap2/2,4 → ap2/5 −76 dBm 20,0 s

🔴 Die Trennlinie ist nicht der Wechsel, sondern das Signal. Bei −48 bis −55 dBm kosten Übergaben 0 bis 2,6 s, meist unter einer halben Sekunde — Fast Transition funktioniert also. Bei −69 bis −77 dBm kostet jeder Wechsel 6 bis 45 s. Dort wechselt das Telefon nicht, es verliert die Verbindung.

5.2 Korrektur des Vorbefunds

Die „~4 Sekunden je Wechsel" aus §4 waren als Obergrenze markiert — zu Recht: bei gutem Signal sind es 0,2 s. Der Zählerstand nach einer Neuanmeldung hat die Lücke vorgetäuscht. Was bleibt, ist der schlimmere Befund: in der schwachen Zone ist das Gerät zweimal über 20 Sekunden nicht erreichbar. Ein Call ist da nicht gestört, er ist tot.

5.3 Was diese Messung NICHT kann

Über den ganzen Weg gingen 44 % der Pings verloren — das ist nicht alles Funk. Ein iPhone mit gesperrtem Display beantwortet ICMP verzögert oder gar nicht; die RTT-Verteilung zeigt es (Median 3,7 ms, 95. Perzentil 124 ms, Maximum 8,2 s = Aufwachen aus dem Ruhezustand).

Warum die Zuordnung oben trotzdem trägt: Power-Save hängt am Displayzustand, nicht am Ort. Dass alle langen Lücken bei −69…−77 dBm liegen und alle kurzen bei −48…−55, lässt sich damit nicht erklären. Für eine Zahl auf zwei Stellen bräuchte es ein waches Telefon — am einfachsten mit laufendem Call, oder indem die Klick-Konsole auf dem iPhone offen bleibt (sie hält per Wake Lock das Display an und pollt alle 3 s).

⚠️ Werkzeug-Fund: die SSH-Sitzung des Samplers ist um 15:09:57 weggebrochen (Can't assign requested address), die Funkdaten enden 2,5 Minuten vor dem Ping-Mitschnitt. tp6-monitor-core.sh hat deshalb jetzt eine Reconnect-Schleife und schreibt RECONNECT in die CSV.

5.4 Die offene Frage an Christoph

Die teure Zone liegt zeitlich bei 15:07–15:09. Wo warst du da? Das ist der Dead Spot, und mit dem Raumnamen wird aus dem Befund eine Maßnahme.


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.