bf-infra/docs/handoff-20260903-tp25-tp28-kanalplan-messung.md

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.