# 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.