Handoff 2026-09-03: TP25/TP28 Kanalplan live, In-situ-Messung in naechster Session
Uebergabeprompt fuer die Messsession: Aufstellorte begehen, entscheiden ob Zielzustand (Template + Commit) oder Nachjustieren. Enthaelt Messplan, Rollback- und Commit-Weg, sowie die relevanten CLAUDE.md-Gotchas (scan/registration-table nur am Manager, cap-wifiN wandert, DFS-CAC). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
113
docs/handoff-20260903-tp25-tp28-kanalplan-messung.md
Normal file
113
docs/handoff-20260903-tp25-tp28-kanalplan-messung.md
Normal file
@@ -0,0 +1,113 @@
|
|||||||
|
# Handoff 2026-09-03 — TP25/TP28: Kanalplan live, In-situ-Messung offen
|
||||||
|
|
||||||
|
**Kurz:** ap1 haengt jetzt am Sideboard (Trunk auf `ether3`), der TP25-Kanalplan ist am
|
||||||
|
Manager gesetzt (**ap1 5260/5280 + ch1**, **ap2 5300/5320 + ch11**, **ap3 5180 + ch6**),
|
||||||
|
und alle drei APs funken. 35 Clients an der Registration-Table (vorher 30, +5 auf ap1).
|
||||||
|
**Was fehlt: die In-situ-Messung** — Aufstellorte begehen und entscheiden, ob der Zustand
|
||||||
|
Zielzustand wird (dann Template + Commit der Akte) oder ob nachjustiert werden muss.
|
||||||
|
|
||||||
|
## Was am 03.09. live gesetzt wurde
|
||||||
|
|
||||||
|
L2 auf `crs326-core`:
|
||||||
|
- `ether3` als AP-Trunk fuer ap1 (analog `ether15`/`ether21`) — Template gepflegt
|
||||||
|
- Akte `TEST-ether3-trunk-ap1-sideboard-2` (Scope `bridge-vlan`, `state=committed`,
|
||||||
|
expires 2026-09-10)
|
||||||
|
|
||||||
|
WLAN am Manager (`crs326-core`):
|
||||||
|
- `ch-5g-ap1`: 5180 → **Frequenz-Liste 5260,5280** (DFS Band B, ch52/56)
|
||||||
|
- `ch-5g-ap2`: 5220 → **Frequenz-Liste 5300,5320** (DFS Band B, ch60/64)
|
||||||
|
- Zwei Provisioning-Regeln fuer ap1 neu (radio-mac `E5`=5G, `E6`=2G) — analog ap2/ap3
|
||||||
|
- `remote-cap provision` auf ap1 und ap2 gefahren
|
||||||
|
- Akte `TP25-kanalplan-ap1-live` (Scope `wifi-channel`, `state=open`, expires 2026-09-10)
|
||||||
|
|
||||||
|
Live-Verifikation:
|
||||||
|
- ap1: 9/9 Interfaces `running=true` am CAP (Manager-Anzeige `running=false` ist der bekannte
|
||||||
|
Post-Reprovisioning-Gotcha, s. CLAUDE.md — Wahrheit am CAP)
|
||||||
|
- ap2: 9/9 Interfaces `running=true`
|
||||||
|
- ap3: unveraendert
|
||||||
|
- 35 Clients (vor Aenderung 30)
|
||||||
|
|
||||||
|
## Was fuer die naechste Session zu tun ist
|
||||||
|
|
||||||
|
**Fokus = messen, nicht nachjustieren, bis die Aufstellorte belegt sind.**
|
||||||
|
|
||||||
|
Zwei offene Frage aus TP25/TP28, die vor Ort beantwortet werden muessen:
|
||||||
|
|
||||||
|
1. **Aufstellort ap1 (Sideboard)** — Abdeckung akzeptabel? Vorher stand ap1 im Technik UG, jetzt
|
||||||
|
am Sideboard (Test). Signal in den Ecken (Terrasse, Bad, hintere Zimmer) messen.
|
||||||
|
2. **ap2 unterperformt** (TP25 Rest-Punkt, In-situ 2 m/−80 dBm am 08-31). Vermutung: RF/Antenne/HW,
|
||||||
|
moeglicherweise auch nur `ch149`-Leistungsproblem (jetzt weg, 5300 statt 5220). Die
|
||||||
|
Kanalaenderung koennte das Symptom bereits behoben haben — deshalb **zuerst neu messen**,
|
||||||
|
bevor man an Antennen oder Hardware denkt.
|
||||||
|
|
||||||
|
## Aufstellorts-Messplan (Vorschlag, bewusst knapp)
|
||||||
|
|
||||||
|
Pro Standort (Wohnzimmer, Kueche, Bad, Terrasse, Schlafzimmer, Technik UG):
|
||||||
|
- Signal in dBm auf `dirtyvader-main` (5 GHz) mit App am Handy
|
||||||
|
- Welcher AP wird ausgewaehlt (BSSID am APx-Radio abgleichen — s. Manager-Registration-Table)
|
||||||
|
- Kurz eine Datei ziehen (SpeedTest oder `iperf3` gegen `10.40.20.10`), damit reale Throughput-
|
||||||
|
Zahl da ist, nicht nur RSSI
|
||||||
|
- 2,4 GHz nur pruefen, wenn das 5-GHz-Signal an dem Standort schlecht ist (< −75 dBm)
|
||||||
|
|
||||||
|
Am Manager parallel:
|
||||||
|
- `/interface wifi registration-table print terse where ssid=dirtyvader-main` — Signal/Rate live
|
||||||
|
- `/interface wifi radio print` gibt aktuelle Frequenz je Radio (5260 vs 5280, 5300 vs 5320 —
|
||||||
|
DFS hat einen der beiden gewaehlt)
|
||||||
|
|
||||||
|
## Gotchas fuer die Messsession (aus CLAUDE.md)
|
||||||
|
|
||||||
|
- **`/interface wifi scan` NUR am Manager**, nicht am CAP (`not allowed`).
|
||||||
|
- **Registration-Table NUR am Manager** — am CAP leer.
|
||||||
|
- **`cap-wifiN`-Karte wandert bei jedem Rejoin.** Vor der Auswertung eines Ereignisses
|
||||||
|
`/interface wifi radio print terse proplist=cap,radio-mac,interface` am Manager lesen; wenn
|
||||||
|
zwischen Ereignis und Auswertung ein Rejoin liegt, Zuordnung als **unbekannt** behandeln.
|
||||||
|
- **`list_wifi_interfaces` leakt PSKs** — nicht benutzen; stattdessen
|
||||||
|
`/interface wifi radio print` bzw. `/interface wifi print terse where master=yes proplist=...`.
|
||||||
|
- **Ein `caps,info`-Burst ist Infrastruktur, ein Client-MAC-Burst ist ein Client** — vor jeder
|
||||||
|
Client-Diagnose `/system resource get uptime` am Core lesen und `grep " caps,"` im TP5-Log.
|
||||||
|
- **DFS-CAC** dauert beim ersten Einschalten eines DFS-Kanals ~60 s. Bei einem Radar-Event
|
||||||
|
wechselt der Kanal automatisch auf den Zweitwert (5260↔5280 bzw. 5300↔5320) — deshalb steht
|
||||||
|
im Channel-Objekt eine **Liste**, kein Einzelwert.
|
||||||
|
|
||||||
|
## Rollback (falls die Messung schlecht ausfaellt)
|
||||||
|
|
||||||
|
Der Snapshot `docs/transaktionen/TP25-kanalplan-ap1-live.snapshot.rsc` haelt den Vorher-Zustand
|
||||||
|
(ap1=5180, ap2=5220, keine ap1-Provisioning-Regeln). Rollback per:
|
||||||
|
|
||||||
|
```
|
||||||
|
python3 nautobot/gc-transaktion.py rollback --change-id TP25-kanalplan-ap1-live
|
||||||
|
```
|
||||||
|
|
||||||
|
Der Trunk auf `ether3` (physischer Umbau) muss separat via
|
||||||
|
`TEST-ether3-trunk-ap1-sideboard-2` behandelt werden.
|
||||||
|
|
||||||
|
## Commit-Weg (falls die Messung gut ausfaellt)
|
||||||
|
|
||||||
|
Zwei Sachen ins Template `nautobot/mikrotik_routeros.j2`:
|
||||||
|
1. Zeilen 206–207: `frequency=5180`/`5220` → Frequenz-Listen `5260,5280`/`5300,5320`
|
||||||
|
2. Nach den bestehenden Provisioning-Zeilen fuer ap2/ap3 die zwei ap1-Regeln einfuegen
|
||||||
|
(radio-mac `D0:EA:11:4D:40:E5` = 5G, `D0:EA:11:4D:40:E6` = 2G) — Slave-Set analog ap2/ap3
|
||||||
|
|
||||||
|
Danach:
|
||||||
|
```
|
||||||
|
python3 nautobot/gc-transaktion.py commit --change-id TP25-kanalplan-ap1-live
|
||||||
|
```
|
||||||
|
|
||||||
|
Skript verweigert den Commit, solange die SoT nicht nachgezogen ist — der Ablauf funktioniert
|
||||||
|
nur in dieser Reihenfolge.
|
||||||
|
|
||||||
|
## Ein-Scope-Grenze der Akte (wichtig, wenn Compliance-Status gelesen wird)
|
||||||
|
|
||||||
|
Die Akte deckt formell **nur `wifi-channel`**. Die zwei ap1-Provisioning-Adds fallen unter
|
||||||
|
`wifi-provisioning` — das begin-Skript erlaubt aber **nur eine offene Akte je Geraet** (Regel 3).
|
||||||
|
Deshalb steht im `commands.rsc` der Akte ein Header, der beides zusammenfuehrt. Im naechsten
|
||||||
|
Compliance-Run wird `wifi-provisioning` als „fremd" (nicht durch die aktive Akte gedeckt)
|
||||||
|
gemeldet werden — das ist **erklaerbarer, nicht undokumentierter Drift**. Beim Commit gehoert
|
||||||
|
BEIDES ins Template.
|
||||||
|
|
||||||
|
## Aufraeumkandidat, wenn alles glatt geht
|
||||||
|
|
||||||
|
- TP25-Ist-Stand-Block: Punkt „ap2 unterperformt" als geloest markieren (falls Messung das
|
||||||
|
bestaetigt).
|
||||||
|
- TP28-Ist-Stand-Block: „ap1 funkstill" ausbauen — ist mit 09-03 erledigt.
|
||||||
|
- Quick-Index-Zeile TP25 kann bei erfolgreichem Commit auf `✅` gesetzt werden.
|
||||||
Reference in New Issue
Block a user