Christoph Emsenhuber
cf44ce6a1e
Die TP6-Praemisse ist ausgefuehrt: drei Messreihen von einem kabelgebundenen Client in VLAN10, zwei davon mit laufendem Telegram-Videocall an zwei Orten. Ergebnis (Runbook §5): unter Dauer-Upload steigt die Latenz von 13 auf 40--60 ms, im Download auf 36--41 ms. Das sind +28 bis +47 ms und damit ueber der Schwelle von 30 ms, die §3 VOR der Messung festgelegt hat -- formal Fall B, CAKE ist begruendet. Die Einschraenkung gehoert zur Zahl: durch alle sechs Lastphasen lief ein Videocall, und es wurde kein einziger Problem-Button gedrueckt. Messbar ja, wahrnehmbar nein. waveform sagt zeitgleich Grade A -- kein Widerspruch, sondern ein kuerzerer Test, dessen Upload-Verteilung zweigipflig ist (25. Perzentil 14,5 ms, 75. Perzentil 47,5 ms). Erstmals dokumentiert: die tatsaechliche Linerate. Upload 9,6 Mbit, Download 54,6 Mbit. Die im Repo kolportierten "~10 Mbit" galten immer nur dem Upload. Der lautere Befund ist ein Nebenprodukt: der Core-Sampler hat 2,5 Stunden lang das iPhone mitgeschrieben. Sticky Client (ein Weg durchs ganze Haus, dreimal direkt an ap1 vorbei, eine einzige Uebergabe -- und die erst oben bei -73 dBm) und Band-Ping-Pong (zwoelf Wechsel in neun Minuten am selben Ort). Je Wechsel bis zu 4 s ohne Durchsatz -- als Obergrenze notiert, denn die Zaehler starten nach einer Neuanmeldung bei null; der saubere Test per ping auf das Telefon steht aus. Das passiert TROTZ aktivem 802.11k/v und FT, live geprueft: damit ist die Merkregel ref_ft_is_not_roaming historisch. Der Bandabstand von 8--10 dB ist dabei normale Physik; das Problem ist, dass 5 GHz an den Telefonier-Orten bei -75 bis -80 dBm landet. Zwei Messfehler bleiben dokumentiert, weil sie die Methode betreffen und beide denselben Typ haben -- die Anzeige war gruen, die Wirkung fehlte: speed.cloudflare.com/__down antwortet ohne User-Agent mit 403 und einem Byte (saubere Ping-Reihe ueber tote Flows), und ein Call lief 5,5 Minuten ohne Treiber (Marker geschrieben, nichts gemessen). Status nachgezogen -- Header inklusive: TP6 von "Praemisse pruefen" auf "gemessen, Fall B, nachrangig", TP25 auf kritischen Pfad. Rohdaten liegen unter docs/messdaten/tp6-20260820/, damit die Zahlen nachpruefbar bleiben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
156 lines
8.1 KiB
Markdown
156 lines
8.1 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 — und was daran noch ungemessen ist
|
||
|
||
Bei **jedem** beobachteten Wechsel steht in den Zählern des Managers für **rund 4 Sekunden** kein
|
||
Durchsatz, danach folgen ~10 Sekunden mit halber PHY-Rate.
|
||
|
||
⚠️ **Diese 4 Sekunden sind eine Obergrenze, kein Beweis.** Nach einer Neuanmeldung beginnen die Zähler
|
||
der Registration-Table bei null; ein Teil der Lücke kann Zähler-Artefakt statt echter Funkstille sein.
|
||
Auch der Rücksprung von `uptime` auf `00:00:00` beweist **nicht**, dass keine Fast Transition stattfand —
|
||
auch eine FT erzeugt am Zielradio einen neuen Eintrag.
|
||
|
||
**Der saubere Test, der das entscheidet** (eine Zeile, read-only, beim nächsten Spaziergang mitlaufen
|
||
lassen — vom Core, damit der Weg kurz ist):
|
||
|
||
```bash
|
||
ping -i 0.2 10.40.10.196
|
||
```
|
||
|
||
Ein Wechsel zeigt sich dann als **echter Paketverlust über N×200 ms**. Fällt dabei nichts aus, ist die
|
||
Übergabe schnell und die 4 Sekunden waren Buchhaltung. Fallen 20 Pakete aus, ist es real — und dann ist
|
||
es die Ursache für die Aussetzer im Call.
|
||
|
||
---
|
||
|
||
## 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.
|