2 Commits

Author SHA1 Message Date
45e4540cf5 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>
2026-09-03 21:38:44 +02:00
e8f58b0e5e TP25/TP28 Kanalplan live: ap1 am Sideboard, ap2+ap1 auf DFS Band B
Sideboard-Test fuer ap1 (TP28) plus Umsetzung des TP25-Kanalplans
in einem Zug am Manager (crs326-core):

L2 (TEST-ether3-trunk-ap1-sideboard-2, bridge-vlan, committed):
- ether3 zum AP-Trunk fuer ap1 hinzugefuegt (analog ether15/ether21)
- Template mikrotik_routeros.j2 nachgezogen: ether3 in allen VLAN-Zeilen

WLAN (TP25-kanalplan-ap1-live, wifi-channel, OFFEN bis 2026-09-10):
- 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)
- Neue Provisioning-Regeln fuer ap1 (radio-mac E5=5G, E6=2G), analog ap2/ap3
- remote-cap provision fuer ap1 und ap2

Live-Ergebnis (35 Clients an der Registration-Table, vorher 30):
- ap1: 5260/5280 + 2412 (ch1), 9/9 Interfaces up
- ap2: 5300/5320 + 2462 (ch11), 9/9 up
- ap3: 5180 + 2437 (ch6), unveraendert
- Keine 5-GHz-Kollisionen mehr, 2,4-GHz sauber auf ch1/6/11

Follow-up in naechster Session: In-situ-Messungen an den Aufstellorten;
bei ok Template auf Frequenz-Listen + ap1-Provisioning-Regeln erweitern
und die offene Akte committen. Snapshot fuer Rollback liegt bereit.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-09-03 18:53:01 +02:00
8 changed files with 206 additions and 11 deletions

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

View File

@@ -0,0 +1,7 @@
/interface bridge vlan set [find where vlan-ids=10 and !dynamic] tagged=ether1,ether3,ether8,ether13,ether15
/interface bridge vlan set [find where vlan-ids=20 and !dynamic] tagged=ether3,ether8,ether13,ether15
/interface bridge vlan set [find where vlan-ids=30 and !dynamic] tagged=ether1,ether3,ether8,ether15
/interface bridge vlan set [find where vlan-ids=40 and !dynamic] tagged=ether1,ether3,ether8,ether13,ether15 untagged=ether2,ether4,ether5
/interface bridge vlan set [find where vlan-ids=50 and !dynamic] tagged=ether1,ether3,ether8,ether15
/interface bridge vlan set [find where vlan-ids=90 and !dynamic] tagged=ether1,ether3,ether8,ether15
/interface bridge vlan set [find where vlan-ids=99 and !dynamic] tagged=ether3,ether8,ether15,bridge

View File

@@ -0,0 +1,15 @@
{
"change_id": "TEST-ether3-trunk-ap1-sideboard-2",
"device": "crs326-core",
"scope": "bridge-vlan",
"match_config": [
"/interface bridge vlan"
],
"reason": "ap1 testweise am Sideboard, Uplink auf ether3 (Messung TP25)",
"started": "2026-09-03",
"expires": "2026-09-10",
"state": "committed",
"snapshot": "docs/transaktionen/TEST-ether3-trunk-ap1-sideboard-2.snapshot.rsc",
"device_backup": "",
"closed": "2026-09-03"
}

View File

@@ -0,0 +1,15 @@
# Snapshot des Scopes 'bridge-vlan' auf crs326-core, 2026-09-03 (Transaktion TEST-ether3-trunk-ap1-sideboard-2)
# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
/interface bridge vlan
add bridge=bridge untagged=ether1,ether2 vlan-ids=1
add bridge=bridge tagged=ether1,ether8,ether13,ether15,ether21 vlan-ids=10
add bridge=bridge tagged=ether8,ether13,ether15,ether21 vlan-ids=20
add bridge=bridge tagged=ether1,ether8,ether15,ether21 untagged=ether14 \
vlan-ids=30
add bridge=bridge tagged=ether1,ether8,ether13,ether15,ether21 untagged=\
ether2,ether3,ether4,ether5 vlan-ids=40
add bridge=bridge tagged=ether1,ether8,ether15,ether21 vlan-ids=50
add bridge=bridge tagged=ether1,ether8,ether15,ether21 vlan-ids=90
add bridge=bridge tagged=ether8,ether15,ether21,bridge vlan-ids=99
add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100

View File

@@ -0,0 +1,19 @@
# Live gesetzt am crs326-core 2026-09-03 (via MikroMCP run_command).
# Zwei Scopes betroffen; die Akte fuehrt formell nur wifi-channel — die zwei
# Provisioning-Adds sind hier mit-dokumentiert, weil das begin-Skript nur einen
# Scope je offener Akte kennt und sie inhaltlich zum selben Test gehoeren.
# Beim Commit gehoert BEIDES ins Template (nautobot/mikrotik_routeros.j2):
# - Zeilen 206-207: frequency=5180/5220 -> Frequenz-Liste 5260,5280 / 5300,5320
# - Zeilen 236f: neue Provisioning-Regeln fuer ap1 (radio-mac E5=5G, E6=2G)
# --- Scope wifi-channel ---
/interface wifi channel set [find name=ch-5g-ap1] frequency=5260,5280
/interface wifi channel set [find name=ch-5g-ap2] frequency=5300,5320
# --- Scope wifi-provisioning (mit-dokumentiert, nicht formell im scope der Akte) ---
/interface wifi provisioning add radio-mac=D0:EA:11:4D:40:E5 action=create-dynamic-enabled master-configuration=cfg-main-5g-ap1 slave-configurations=cfg-media,cfg-untrusted,cfg-guest comment="ap1 5GHz"
/interface wifi provisioning add radio-mac=D0:EA:11:4D:40:E6 action=create-dynamic-enabled master-configuration=cfg-main-2g-ap1 slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest comment="ap1 2.4GHz"
# Anschliessend am Manager:
/interface wifi capsman remote-cap provision [find where identity=ap1]
/interface wifi capsman remote-cap provision [find where identity=ap2]

View File

@@ -0,0 +1,14 @@
{
"change_id": "TP25-kanalplan-ap1-live",
"device": "crs326-core",
"scope": "wifi-channel",
"match_config": [
"/interface wifi channel"
],
"reason": "TP25-Kanalplan live: ap1=5260/5280, ap2=5300/5320 (DFS Band B). Testet den Zielzustand nach TP25 (dritter AP + ap2-Umverteilung) am tatsaechlichen Aufstellort. Bei ok: Template auf Frequenz-Listen umstellen und committen. Bei nicht ok: zurueck auf 5180/5220 (Snapshot).",
"started": "2026-09-03",
"expires": "2026-09-10",
"state": "open",
"snapshot": "docs/transaktionen/TP25-kanalplan-ap1-live.snapshot.rsc",
"device_backup": ""
}

View File

@@ -0,0 +1,10 @@
# Snapshot des Scopes 'wifi-channel' auf crs326-core, 2026-09-03 (Transaktion TP25-kanalplan-ap1-live)
# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
/interface wifi channel
add band=5ghz-ax frequency=5260,5280 name=ch-5g-ap1 width=20/40mhz
add band=5ghz-ax frequency=5300,5320 name=ch-5g-ap2 width=20/40mhz
add band=2ghz-ax frequency=2412 name=ch-2g-ap1 width=20mhz
add band=2ghz-ax frequency=2462 name=ch-2g-ap2 width=20mhz
add band=5ghz-ax frequency=5180 name=ch-5g-ap3 width=20/40mhz
add band=2ghz-ax frequency=2437 name=ch-2g-ap3 width=20mhz

View File

@@ -51,10 +51,10 @@
# [0] L2-FABRIC — Bridge-Ports + Bridge-VLAN-Tabelle. # [0] L2-FABRIC — Bridge-Ports + Bridge-VLAN-Tabelle.
# Literal-Block, KEINE Ableitung aus DCIM: der As-built traegt bewusste Schiefstaende # Literal-Block, KEINE Ableitung aus DCIM: der As-built traegt bewusste Schiefstaende
# (ether3 ist untagged-Member von VLAN40, hat aber pvid=1; ether2 haengt zusaetzlich in # (ether2 haengt zusaetzlich in VLAN1). Wuerde man pvid aus `untagged_vlan` generieren,
# VLAN1). Wuerde man pvid aus `untagged_vlan` generieren, meldete die Compliance genau # meldete die Compliance genau diese akzeptierten Altlasten als Dauerdrift. Der Block ist
# diese akzeptierten Altlasten als Dauerdrift. Der Block ist damit das, was Golden Config # damit das, was Golden Config fuer einen handgebauten L2-Layer leisten soll:
# fuer einen handgebauten L2-Layer leisten soll: Drift-Erkennung gegen den Ist-Zustand. # Drift-Erkennung gegen den Ist-Zustand.
# `/interface bridge` selbst ist bewusst NICHT abgedeckt (traegt die geraetespezifische # `/interface bridge` selbst ist bewusst NICHT abgedeckt (traegt die geraetespezifische
# admin-mac -> waere pro Geraet verschieden und ist kein Fleet-Standard). # admin-mac -> waere pro Geraet verschieden und ist kein Fleet-Standard).
/interface bridge port add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether1 /interface bridge port add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether1
@@ -86,13 +86,15 @@
# ether21 = ap3 (cAP ax, Technik UG) seit 2026-08-30, TP28-Nachtrag: gleicher AP-Trunk # ether21 = ap3 (cAP ax, Technik UG) seit 2026-08-30, TP28-Nachtrag: gleicher AP-Trunk
# wie ether15/ap1. Der Port traegt pvid=1 + frame-types=admit-all wie ether15 -- das # wie ether15/ap1. Der Port traegt pvid=1 + frame-types=admit-all wie ether15 -- das
# VLAN1-untagged-Bein entsteht dynamisch aus dem pvid und steht deshalb nicht hier. # VLAN1-untagged-Bein entsteht dynamisch aus dem pvid und steht deshalb nicht hier.
/interface bridge vlan add bridge=bridge tagged=ether1,ether8,ether13,ether15,ether21 vlan-ids=10 # ether3 = ap1 (hAP ax2) seit 2026-09-03, TP25-Sideboard-Test: ap1 testweise am Sideboard,
/interface bridge vlan add bridge=bridge tagged=ether8,ether13,ether15,ether21 vlan-ids=20 # Uplink von ether15 auf ether3 verlegt. Gleicher AP-Trunk wie ether15.
/interface bridge vlan add bridge=bridge tagged=ether1,ether8,ether15,ether21 untagged=ether14 vlan-ids=30 /interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether13,ether15,ether21 vlan-ids=10
/interface bridge vlan add bridge=bridge tagged=ether1,ether8,ether13,ether15,ether21 untagged=ether2,ether3,ether4,ether5 vlan-ids=40 /interface bridge vlan add bridge=bridge tagged=ether3,ether8,ether13,ether15,ether21 vlan-ids=20
/interface bridge vlan add bridge=bridge tagged=ether1,ether8,ether15,ether21 vlan-ids=50 /interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether15,ether21 untagged=ether14 vlan-ids=30
/interface bridge vlan add bridge=bridge tagged=ether1,ether8,ether15,ether21 vlan-ids=90 /interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether13,ether15,ether21 untagged=ether2,ether4,ether5 vlan-ids=40
/interface bridge vlan add bridge=bridge tagged=ether8,ether15,ether21,bridge vlan-ids=99 /interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether15,ether21 vlan-ids=50
/interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether15,ether21 vlan-ids=90
/interface bridge vlan add bridge=bridge tagged=ether3,ether8,ether15,ether21,bridge vlan-ids=99
/interface bridge vlan add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100 /interface bridge vlan add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100
# [1] INTERFACE-LISTS # [1] INTERFACE-LISTS