Initial import from bf-network-r6.opencode — opencode migration

docs/tp25-wlan-roaming-messung-20260820.md

@@ -0,0 +1,294 @@
+# 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.