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

# 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.