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