# 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. Raumkarte (2026-08-21, zweiter Durchgang) — der Dead Spot hat einen Namen **Methode korrigiert gegenüber §5:** gepingt wurde **vom Core** (Kabel bis zum AP, damit der Verlust eindeutig dem Telefon gehört), und die Konsole lag **auf dem iPhone** (Wake Lock hält es wach — sonst misst man Ruhezustand). Raumwechsel per Klick markiert. 10 Minuten, 2.926 Pings, 13 Raumsegmente. Rohdaten: `docs/messdaten/tp25-raumkarte-20260821/`. | Raum | Signal min/avg/max | Verlust | längste Lücke | AP | |---|---|---|---|---| | Technik OG | −60 / −56 / −43 | **0 %** | keine | ap2/5 | | Arbeitszimmer | −56 / −49 / −39 | **0 %** | keine | ap2/5 | | Treppe | −68 / −51 / −37 | **0 %** | 0,2 s | ap1+ap2/5 | | Schlafzimmer | −64 / −61 / −57 | **0 %** | keine | ap1/5 | | Kinderzimmer | −58 / −53 / −41 | **0 %** | keine | ap1/5 | | Diele UG | −57 / −44 / −35 | **0 %** | keine | ap1/5 | | Technik UG | −44 / −43 / −41 | **0 %** | keine | ap1/5 | | **Terrasse** | **−74 / −72 / −69** | **43 %** | **20,4 s** | ap2/5 | 🔴 **Im ganzen Haus: null Verlust.** Jeder Raum, jede Übergabe, beide APs — sauber. Die Wechsel ap1↔ap2 auf der Treppe kosten **0,2 s**. Das Netz funktioniert. 🔴 **Die Terrasse ist der einzige Dead Spot** — und dort ist es nicht knapp, sondern kaputt: über 162 Sekunden gingen **290 von 670 Pings** verloren, am Stück fehlten **20,4 Sekunden**. Ein Videocall ist dort nicht gestört, er ist weg. **Die Topologie erklärt es** (User, 2026-08-21, korrigiert): - **„Technik OG" ist kein eigener Raum**, sondern ein virtueller Bereich **im Arbeitszimmer** — dort gibt es keine bauliche Trennung. ap2 steht also effektiv im Arbeitszimmer. *(Die frühere Fassung dieses Absatzes zählte drei Wände; das war falsch.)* - Zwischen ap2 und Terrasse liegt die **Diele OG: zwei Mauern — und teilweise die PV-Anlage an der Mauer.** - Das **Wohnzimmer liegt unterhalb der Terrasse** und ist als AP-Standort verfügbar. 🔴 **Die PV-Anlage ist der entscheidende Punkt.** Module und Unterkonstruktion sind eine leitende Fläche; das ist kein dämpfendes Mauerwerk, sondern ein **Schirm**. Damit ist erklärt, warum es auf der Terrasse nicht *knapp*, sondern *kaputt* ist — und es sagt voraus, dass mehr Sendeleistung oder ein schmalerer Kanal dort wenig ausrichten. **Gegen einen Schirm hilft, ihn zu umgehen, nicht ihn zu durchdringen.** ### 6.1 Was das an den Handlungsoptionen ändert ⚠️ **Fund E (`signal-range`-Boden) würde die Terrasse VERSCHLECHTERN.** Ein Boden nimmt einem Client den schlechten AP weg, damit er den besseren nimmt — auf der Terrasse **gibt es keinen besseren**. Dort führte der Boden zum vollständigen Rauswurf statt zu einer besseren Verbindung. Der Boden bleibt sinnvoll, aber **nur für Innenräume mit Alternative**, und er löst das gemessene Problem nicht. ✅ **Was es stattdessen braucht, in dieser Reihenfolge:** 1. **5 GHz auf 20 MHz** (statt 20/40) — **+3 dB**, kostet nichts, ist ein Ein-Wort-Change im GC-Template. Danach die Terrasse erneut messen: hebt es sie von −72 auf ~−69, ändert das wenig; der Versuch ist trotzdem billiger als jede Hardware. 2. **ap2 testweise an den Kandidatenplatz hängen** (User-Vorschlag 2026-08-21): dorthin, wo später ohnehin ein Decken-AP fürs OG sitzen würde. **Kein neuer AP und kein Config-Change** — ap2 ist ein CAP und holt sich am neuen Platz alles vom Manager; nötig sind nur PoE und die Leitung von `crs326-branch ether24`, für den Test genügt ein provisorisches Kabel. **Abnahme ist derselbe Gang mit demselben Skript**, sonst sind die Zahlen nicht vergleichbar. 3. **Bleibt die Terrasse dabei schlecht, ist das OG die falsche Seite.** Dann ist das **Wohnzimmer** der Kandidat: es liegt **unterhalb** der Terrasse, ein AP dort strahlt an der PV-Anlage **vorbei** statt durch sie hindurch — die Konsequenz aus dem Schirm-Befund oben. 4. **Dritter AP** danach, und dann mit Messdaten statt Bauchgefühl, welcher Platz er sein muss. --- ## 7. Raumkarte 2 (2026-08-21 abends) — ap1 am Sideboard, und ein Steering-Verdacht ap1 wurde physisch versetzt (Uplink jetzt `crs326-core ether3`, s. offene Transaktion `TEST-ether3-trunk-ap1-sideboard`). Derselbe Gang, dieselben Werkzeuge. Signal = Durchschnitt. | Raum | Karte 1 (ap1 alt) | Karte 2 (ap1 Sideboard) | | |---|---|---|---| | Diele UG | −44 (ap1/5) | −69 | schlechter | | Kinderzimmer | −53 (ap1/5) | −75 | schlechter | | **Schlafzimmer** | **−61** (ap1/5) | **−83** (ap2/**2,4**) | **−22 dB** | | Bad | — | −83, 31 % Verlust | schlecht | | Küche / Wohnzimmer | — | −61 / −59 (ap1/5) | gut | | Arbeitszimmer / Technik OG | −49 / −56 | −50 / −44 | gut bis besser | | **Diele OG** | — | **−50**, 0 % über 5,5 min | **sehr gut** | **Das Sideboard verbessert das OG und opfert die Schlafräume.** ### 7.1 Warum das vermutlich kein Abdeckungsproblem ist Maßangaben des Users (2026-08-21): Schlaf- und Kinderzimmer liegen **2 bzw. 4 m Luftlinie von ap1**; **ap2** ist 4–6 m entfernt und hat **zwei zusätzliche Mauern** dazwischen. Gemessen wurde trotzdem `ap2 / 2,4 GHz / −83 dBm`. 🔴 **Ein Client, der bei 2 m Luftlinie zum besseren AP am schlechteren klebt, hat ein Steering-Problem, kein Abdeckungsproblem.** Und damit ist das die erste Stelle in diesem Haus, an der **Fund E (`signal-range`-Boden) tatsächlich das richtige Werkzeug ist** — hier existiert eine bessere Alternative, auf der Terrasse (§6) existiert keine. **Test vor jeder Maßnahme:** derselbe Gang, aber in jedem Schlafraum stehen bleiben und alle 10–20 s die Konsole antippen; protokollieren, ob und wann der Client auf ap1 wechselt. ### 7.2 Zwei Korrekturen aus diesem Lauf 1. **Die Terrasse ist differenzierter als in §6 geschrieben.** Der Platz, an dem das Telefon normalerweise steht, liegt bei **−46 bis −66 dBm** — der Dead Spot ist der Teil **dahinter**. 2. **Die 51 % Verlust dieses Laufs auf der Terrasse sind KEIN Funkloch**, sondern Ruhezustand: während der 58-Sekunden-Lücke stand der Client bei **−53 dBm, 275–309 Mbps PHY-Rate** und hatte weiter 3 kbit/s Hintergrundverkehr. Die Auswertung markiert solche Lücken seitdem selbst. **Lange unmarkierte Abschnitte ohne Interaktion sind für Verlustzahlen wertlos** — die Signalwerte bleiben gültig. --- ## 8. 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. --- ## 9. 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.