# Übergabe: TP25-Session — vom Verdacht zur Raumkarte

> **Stand bei Übergabe: 2026-08-21, alles live verifiziert und committet.** Diese Datei ist der
> Einstieg. Der Arbeitsplan steht in [`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md);
> hier steht, was du wissen musst, bevor du ihn aufschlägst.

---

## 1. Dein Auftrag in zwei Sätzen

**TP25 ist der kritische Pfad.** TP6 ist am 2026-08-20/21 gemessen und entschieden — formal Fall B,
aber im Videocall nicht wahrnehmbar; die Zahlen stehen in [`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5
und TP6 ist bewusst **nachrangig**. Was die Calls tatsächlich zerreißt, ist der Funk, und der ist jetzt
raumgenau vermessen.

---

## 2. 🔴 Zuerst: es ist eine Transaktion offen

```
TEST-ether3-trunk-ap1-sideboard    OFFEN    crs326-core    Scope bridge-vlan    Frist 2026-09-04
```

**Die Compliance ist absichtlich nicht 92/92.** `ether3` wurde zum Trunk gemacht, damit ap1 an seinem
neuen Platz (Sideboard) überhaupt läuft — die Änderung steht **am Gerät**, aber **nicht in der SoT**.
Das ist kein Versehen, sondern der Zustand „uncommitted".

```bash
python3 nautobot/gc-transaktion.py status
```

**Geschlossen wird sie so:**

- **Bleibt ap1 am Sideboard** → Template nachziehen (`ether3` in die sieben `tagged`-Listen,
  **und aus der `untagged`-Liste von VLAN 40 raus**), dann `--refresh-compliance`, dann
  `gc-transaktion.py commit --change-id TEST-ether3-trunk-ap1-sideboard`. Der Commit **verweigert
  sich**, solange der Scope noch driftet — das ist die eingebaute Sicherung gegen einen Commit, der
  nur behauptet, die SoT sei nachgezogen.
- **Geht ap1 zurück auf ether15** → `gc-transaktion.py rollback --change-id …` erzeugt aus dem
  Snapshot einen Rückbau-**Vorschlag**; prüfen, per `gc-manual-plan.py` deployen, dann
  `rollback --erledigt`.

Hintergrund zum Mechanismus: [`docs/transaktionen/README.md`](transaktionen/README.md).

---

## 3. Verifizierter Ist-Stand (nichts davon neu erheben)

| | |
|---|---|
| **ap1** | **am Sideboard**, Uplink `crs326-core ether3` (trägt jetzt VLAN 10/20/30/40/50/90/99), erreichbar in 447 µs, **12 Clients** |
| **ap2** | unverändert **am Boden im Arbeitszimmer**, 16 Clients |
| SSIDs auf Sendung | **fünf**, nicht sechs: main, iot, media, untrusted, guest. `cfg-infra` existiert als Objekt, ist aber **in keiner Provisioning-Regel** → nie ein VAP. Kein Drift. |
| pro Radio | 5 GHz: 4 SSIDs · 2,4 GHz: 5 SSIDs (Beacon-Airtime, relevant in dichter Nachbarschaft) |
| 802.11k/v/FT | **aktiv** (`st-main`, `rrm=yes`, `wnm=yes`, `ft-over-ds=yes`) — `ref_ft_is_not_roaming` ist historisch |
| Kanäle | ap1 5180 (ch36) / 2412 · ap2 5220 (ch44) / 2462, 5 GHz auf **20/40 MHz** |
| Übergabekosten | bei gutem Signal **0–2,6 s**, meist unter 0,4 s — gemessen, nicht geschätzt |
| TP6 | Upload-Last +28…+47 ms; Call lief durch **ohne einen einzigen Problem-Klick** |
| Linerate | **9,6 Mbit up / 54,6 Mbit down** (stand vorher nirgends im Repo) |

---

## 4. Messstand TP25 — zwei Raumkarten

**Raumkarte 1**, ap1 am alten Platz (2026-08-20 abends) · **Raumkarte 2**, ap1 am Sideboard (2026-08-21).
Signal = Durchschnitt, wie der Manager den Client sieht.

| Raum | Karte 1 | Karte 2 | |
|---|---|---|---|
| Technik UG | −43 (ap1/5) | — | |
| Diele UG | **−44** (ap1/5) | **−69** | schlechter |
| Kinderzimmer | **−53** (ap1/5) | **−75** | schlechter |
| Schlafzimmer | **−61** (ap1/5) | **−83** (ap2/**2,4**) | **deutlich schlechter** |
| Bad | — | **−83**, 31 % Verlust | schlecht |
| Küche | — | −61 (ap1/5) | gut |
| Wohnzimmer | — | −59 (ap1/5) | gut |
| Treppe | −51 | −62 | ok |
| Arbeitszimmer | −49 | −50 | gut |
| Technik OG | −56 | −44 | besser |
| Diele OG | — | **−50**, 0 % über 5,5 min | **sehr gut** |
| Terrasse | −72, 43 % Verlust, 20,4 s Lücke | −55 am Telefon-Platz | s. u. |

**Zur Terrasse, korrigiert:** der Platz, an dem das Telefon normalerweise steht, ist mit **−46 bis
−66 dBm gut**. Schlecht ist der Teil **dahinter** (Karte 1, −72 dBm). Die 51 % Verlust in Karte 2 sind
**kein Funkloch**, sondern Ruhezustand — siehe §6.

**Kurzfassung:** das Sideboard verbessert das OG und opfert die Schlafräume.

---

## 5. Die Frage, die als Nächstes drankommt

Christophs Maßangaben (2026-08-21) drehen den Befund um:

> Schlafzimmer und Kinderzimmer liegen **2 bzw. 4 m Luftlinie von ap1**. ap2 ist 4–6 m entfernt, mit
> **zwei zusätzlichen Mauern** dazwischen. Kinderzimmer liegt **< 1 m** an der Trennmauer zum Schlafzimmer.

Gemessen wurde aber: beide Räume hängen an **ap2 auf 2,4 GHz bei ⌀ −83 dBm**.

🔴 **Ein Client, der bei 2 m Luftlinie zum besseren AP am schlechteren klebt, hat kein
Abdeckungsproblem, sondern ein Steering-Problem.** Damit ist das die erste Stelle in diesem Haus, an
der **Fund E (`signal-range`-Boden) wirklich hilft** — hier gibt es eine bessere Alternative; auf der
Terrasse gab es keine, dort hätte derselbe Boden nur rausgeworfen.

**Test, bevor irgendetwas gesetzt wird:**

```bash
bash docs/tp25-walk-messung.sh
```

Derselbe Gang, aber in **jedem Schlafraum stehen bleiben** und **alle 10–20 s die Konsole antippen**
(hält das Telefon wach — sonst sind die Verlustzahlen wertlos, s. §6). Protokollieren, **ob und wann**
der Client von ap2 auf ap1 wechselt. Auswertung:
`python3 docs/tp25-gehweg-auswertung.py --dir <run-dir>`.

---

## 6. Fallen, die in dieser Session je einen Fehlbefund gekostet haben

| Falle | Symptom | Merkregel |
|---|---|---|
| **Ruhezustand ≠ Funkloch** | 58 s Ping-Lücke bei −53 dBm und 275 Mbps PHY | iOS beantwortet ICMP mit gesperrtem Display nicht. Bleibt Signal **und** Rate hoch, war das Gerät erreichbar. Die Auswertung markiert das jetzt. |
| **Teilzustand nach `Failed`** | 6 von 7 VLANs gesetzt | `ether3` war in VLAN 40 **untagged** — ein Port kann nicht zugleich tagged und untagged sein. Nach jedem Fehlschlag am Gerät nachzählen. |
| **CF-403 ohne User-Agent** | saubere Ping-Reihe über tote Flows | `speed.cloudflare.com/__down` antwortet `curl` mit 403 + 1 Byte. Aufgefallen nur am Core-Sampler (164 kbit statt 50 Mbit). |
| **Treiber-Heartbeat** | 5,5 min Call ohne Messung | Start-Klick ohne laufenden Treiber schreibt nur einen Marker. Die Konsole warnt jetzt sichtbar. |
| **RouterOS + SSH-Mehrzeiler** | `expected closing brace` | Die Console parst zeilenweise; als Einzeiler braucht jeder `do={}`-Block ein abschließendes `;`. |
| **`tr` puffert blockweise** | CSV scheinbar leer | In Pipes 4-KB-Puffer. `\r` im Shell-Loop entfernen, nicht per `tr`. |
| **Marker URL-kodiert** | `RAUM%3DDIELE%20OG` | Erst `unquote`, dann **nicht** hochschreiben. |
| **`NAUTOBOT_TOKEN`** | Abbruch nach dem Dry-Run | `gc-manual-plan.py` braucht die Variable im Environment (steht in `docs/nas-vlan20/stacks/210-nautobot.yml`, gitignored). |

---

## 7. Werkzeug, das diese Session hinterlässt

| Datei | Zweck |
|---|---|
| [`tp6-monitor-core.sh`](tp6-monitor-core.sh) | Core-Sampler: CPU, WAN-Rate, Client-Funkwerte im Sekundentakt, mit Reconnect |
| [`tp25-walk-messung.sh`](tp25-walk-messung.sh) | Gehweg-Messung: Ping **vom Core** aufs Telefon + Sampler |
| [`tp6-marker/server.py`](tp6-marker/server.py) | Klick-Konsole fürs Telefon: Phasen, Anweisungen, Not-Aus, **Raum-Buttons** |
| [`tp25-gehweg-auswertung.py`](tp25-gehweg-auswertung.py) | Tabelle je Raum: Signal, Verlust, längste Lücke, AP |
| [`tp6-auswertung.py`](tp6-auswertung.py) | Phasenauswertung der Sampler-CSV |
| [`../nautobot/gc-transaktion.py`](../nautobot/gc-transaktion.py) | `begin`/`status`/`commit`/`rollback` für Teständerungen |

Rohdaten aller Läufe: `docs/messdaten/`.

---

## 8. Spielregeln (unverändert, plus eine neue)

1. **Config-Änderungen ausschließlich über Nautobot Golden Config.** Kein Direkt-Write per MikroMCP.
2. **NEU: Teständerungen bekommen eine Transaktion.** `gc-transaktion.py begin` vor dem Deploy —
   mit Scope und Frist. Ein Drift ohne Akte ist ab jetzt ein Fehler, kein Versuch.
3. **Abnahme misst Wirkung, nicht Anzeige.** `--assert` liest am Gerät; bei Funkänderungen `monitor`,
   nie das Profil.
4. **Bei Statuswechseln den Header mitziehen.** Der wiederkehrende Fehler dieses Repos.
5. **Eine Session zur Zeit an diesem Repo.** `git pull` vor dem ersten Edit.

## 9. Nicht dein Auftrag

TP6 neu aufrollen (gemessen und entschieden), Fasttrack-Reihenfolge (entschieden), CF-Writes.
Und: **kein neuer AP**, solange die User-Randbedingung gilt — erst muss aus den vorhandenen alles
herausgeholt sein, und mit dem Steering-Test aus §5 ist genau das noch offen.