Christoph Emsenhuber
e6efa2d562
Uebergabedokument nach dem Muster des TP6-Handovers, das sich bewaehrt hat. Sein Wert liegt in zwei Dingen, die eine frische Session nicht selbst herausfinden kann: die offene Config-Transaktion mit Frist, und die acht Messfallen, die in dieser Session je einen Fehlbefund produziert haben. Der Statusstand: TP6 gemessen und nachrangig, TP25 auf dem kritischen Pfad, und auf crs326-core ist TEST-ether3-trunk-ap1-sideboard offen (Frist 2026-09-04) -- die Compliance ist deshalb absichtlich nicht 92/92. Inhaltlich neu ist die Umdeutung des Abend-Befunds. Nach dem ap1-Umzug ans Sideboard verlieren die Schlafraeume rund 20 dB und fallen auf ap2/2,4 GHz zurueck. Laut Christophs Massangaben liegen sie aber 2 bzw. 4 m Luftlinie von ap1, waehrend ap2 4-6 m entfernt ist und zwei zusaetzliche Mauern dazwischen hat. Ein Client, der so am ferneren AP klebt, hat kein Abdeckungs-, sondern ein Steering-Problem -- und damit ist das die erste Stelle im Haus, an der Fund E (signal-range-Boden) wirklich das richtige Werkzeug ist. Auf der Terrasse waere er falsch gewesen, weil es dort keine Alternative gibt. Der Test dafuer steht im Handover und ist die naechste Messung. Ebenfalls korrigiert: der Platz, an dem das Telefon auf der Terrasse normalerweise steht, ist mit -46 bis -66 dBm gut. Der Dead Spot ist der Teil dahinter. TP29 haelt Christophs Idee fest, Anwesenheit ueber BLE (Shellys), WLAN und mmWave-Radar zu erkennen, um ohne Komfortverlust zu heizen. Der Entwurfsgedanke sind die komplementaeren Schwaechen der drei Quellen -- BLE braucht ein getragenes Geraet, WLAN erkennt nur Menschen mit Telefon, Radar auch die stillsitzende Person, kostet aber einen Sensor je Raum. Nicht auf dem kritischen Pfad. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
163 lines
8.5 KiB
Markdown
163 lines
8.5 KiB
Markdown
# Ü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.
|