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>
10 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 — 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.
- 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.