Christoph Emsenhuber
6cd41d5e9b
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>
189 lines
10 KiB
Markdown
189 lines
10 KiB
Markdown
# 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.
|