TP28: ap3 (cAP ax) live als CAP, ap1 funkstill, Compliance 130/130 ueber 5 Geraete

Der dritte Access-Point laeuft: 10.40.99.13 auf vlan99, Uplink ether1 -> core ether21,
reiner CAP unter crs326-core, Kanaele 5180/ax/Ce/I und 2437/ax (ch6) -- am Geraet
nachgemessen, nicht aus dem Plan abgeschrieben. Der Kanalplan stammt aus TP25 vom
2026-08-24; mein erster Entwurf hatte ihn neu erfunden und waere bei ch1 statt ch6
gelandet. Lehre: den TP-Body lesen, nicht nur den Quick-Index.

ap1 hat bewusst KEINE Provisioning-Regel mehr: es steht bis zu seinem Umzug ans
Sideboard direkt neben ap3 und wuerde auf 5180 kollidieren. Geraet bleibt erreichbar,
die Objekte ch-*-ap1 / cfg-main-*-ap1 bleiben fuer den Umzug stehen.

Bring-up in zwei Phasen ueber ein Patchkabel ap3 ether2 -> core ether22, weil ueber
ether1 nichts ging (s.u.). Loop-Schutz: ether21 war waehrend Phase 1 abgeschaltet und
wurde im selben Befehl gegen ether22 getauscht. RouterOS 7.20.8 -> 7.24.1 plus
RouterBOOT (zwei Reboots, TP27-Kriterium erfuellt). Die anderen vier stehen auf 7.24 --
die Angleichung ist ein eigener Durchgang, der Core-Reboot ist ein Standort-Ausfall.

Nautobot: DeviceType "cAP ax", Device ap3 mit 16 Interfaces, primary_ip4, secrets_group,
ConfigContext 5g=ch36 2g=ch6 extra_ports=[]. Nebenkorrektur: ap1 stand auf "Wohnzimmer
Sideboard", steht physisch aber in Technik UG (User-Bestaetigung).

Sechs Funde, alle als Gotcha in CLAUDE.md und im Handoff:
- ether1 ist am Werksgeraet WAN: Discovery aus, Input-TCP verworfen, ICMP aber erlaubt.
  Es pingt, und das liest sich wie "erreichbar". MikroMCP hilft nicht -- Port 80 ist zu.
- pvid ist Ingress, tagged/untagged ist Egress. Ein Lease hing ewig auf "offered", weil
  der ACK getaggt rausging und ein Werksgeraet das nicht versteht.
- `cap enabled=yes` reicht nicht: jedes Master-Radio braucht configuration.manager=capsman,
  sonst bietet der CAP seine Radios gar nicht an -- state=Ok, radio-Tabelle leer.
- Ein Geraet ohne secrets_group erzeugt eine LUECKE, keine Fehlermeldung: Backup scheitert
  still, keine Compliance-Eintraege, Zahl bleibt unauffaellig bei 104/104. Eine
  gleichbleibende Compliance-Zahl nach dem Hinzufuegen eines Geraets ist ein BEFUND.
- CAPsMAN verteilt keine Login-Passwoerter, nur WLAN-PSKs. Der Geraete-Login ist eine
  lokale DB pro Geraet; das einheitliche Admin-PW ist eine Konvention von Hand.
- Firewall-Regelnummern aus `print where` sind Handles, keine Positionen. Beweis ist der
  Zaehler, nicht die Zahl.

Abnahme: 3 CAPs state=Ok, VAP-Satz vollstaendig und running, 20 IOT-Clients auf ap3 mit
0 % Ping-Verlust ueber VLAN30 (bewusst nicht ueber die Registration-Table abgenommen),
Compliance 130/130 / 0 Drifts, Core-Temp-Pfad restlos abgeraeumt.

Offen: TP25-Messrunde (braucht Rundgang), PW-Rotation TP30, MikroMCP-Neustart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/handoff-20260830-ap3.md

@@ -0,0 +1,82 @@
+# Handoff 2026-08-30 — ap3 (cAP ax) live, TP28 wieder geöffnet und durchgezogen
+
+## Was jetzt gilt
+
+**ap3 funkt.** MikroTik cAP ax (`cAPGi-5HaxD2HaxD`), `10.40.99.13/24` auf `vlan99`, Uplink
+`ether1` → **`crs326-core ether21`**, reiner CAP unter `crs326-core`. Kanäle **`5180/ax/Ce/I`**
+(5 GHz) und **`2437/ax`** (ch6) — am Gerät nachgemessen, nicht aus dem Plan abgeschrieben.
+
+**ap1 ist funkstill.** Es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und würde auf
+5180 kollidieren. Es hat deshalb **keine Provisioning-Regel** am Manager; das Gerät bleibt
+erreichbar, die Objekte `ch-*-ap1`/`cfg-main-*-ap1` bleiben für den Umzug stehen.
+
+**Compliance: 130/130, 0 Drifts über 5 Geräte.**
+
+## Was noch offen ist
+
+1. **TP25-Messrunde** — `bash docs/tp25-runde.sh ap3-bringup`, dann `docs/tp25-walk-messung.sh`
+   für den Gehweg Technik UG ↔ OG. Braucht einen Rundgang mit dem Telefon.
+   Leitfrage: **deckt ap3 allein ab, was ap1 abgedeckt hat, oder klafft bis zum Umzug eine Lücke?**
+2. **Passwort-Rotation (TP30)** — das gemeinsame MikroTik-Admin-PW ist in dieser Session
+   verbrannt (ungefilterte Ausgabe des `mikromcp`-`env`-Blocks aus `~/.claude.json`). ap3 trägt es
+   bereits, hängt also in der Rotation mit drin. Fehlen zusätzlich in `~/.secrets/exports.zsh`:
+   `MCP_MIKROMCP_ROUTER_AP3_PASS`, `MCP_MIKROMCP_CRS326_CORE_PASS`, `MCP_MIKROMCP_CRS326_BRANCH_PASS`.
+3. **MikroMCP-Neustart** — Registry (jetzt `bf-infra`, mit ap3) wird nur beim Start gelesen.
+4. **Versions-Differenz** — ap3 läuft auf **7.24.1**, die anderen vier auf **7.24**. Bewusst:
+   7.20.8 (Januar, long-term) wäre ein halbes Jahr Abstand zur `/interface wifi`-Implementierung
+   des Managers gewesen. Die Angleichung der Flotte ist ein eigener TP27-Durchgang — der
+   Core-Reboot ist ein Standort-Ausfall und damit Terminentscheidung.
+5. **Kabel `ap3 ether2` → `core ether22`** kann raus. Seit Phase 2 ist `ether2` kein Bridge-Port
+   mehr, das Kabel ist inert.
+6. **Offene Frage aus TP22:** auf den APs deckt **keine ComplianceRule** `/interface wifi` ab.
+   Genau dort sitzt `configuration.manager=capsman` — ein Feld, dessen Fehlen das WLAN eines APs
+   still verhindert (s. unten). Ob dafür eine Regel sinnvoll ist, ist noch nicht entschieden.
+
+## Die sechs Funde, die Zeit gekostet haben
+
+1. **`ether1` ist am Werksgerät WAN.** Discovery aus (kein MNDP), Input-TCP verworfen
+   (22/80/8291/8728 zu) — **aber ICMP erlaubt**. Es *pingt*, und das liest sich wie „erreichbar".
+   MikroMCP hilft nicht: es ist ein HTTP-Client auf Port 80, und der ist zu. Gegenprobe, dass der
+   Core nicht schuld war: Regel 44 `MAIN->MGMT` ist `action=accept` **ohne** Port-Einschränkung.
+2. **`pvid` ist Ingress, `tagged`/`untagged` ist Egress.** Ein DHCP-Lease hing ewig auf `offered`,
+   ARP auf `failed`: `pvid=99` nahm den DISCOVER an, aber der Port stand in der *tagged*-Liste von
+   VLAN99 — der ACK ging getaggt raus, ein Werksgerät versteht das nicht.
+3. **`cap enabled=yes` reicht nicht.** Jedes Master-Radio braucht zusätzlich
+   `configuration.manager=capsman`, sonst bietet der CAP seine Radios dem Manager gar nicht an:
+   `remote-cap print` zeigt `state=Ok`, `/interface wifi radio print` bleibt leer — und man sucht
+   den Fehler in der `radio-mac`.
+4. **Ein neues Gerät ohne `secrets_group` erzeugt eine Lücke, keine Fehlermeldung.** Der Backup-Job
+   scheitert still, die *intended* config wird trotzdem gerendert, und ohne Backup entstehen keine
+   Compliance-Einträge. Die Zahl blieb bei **104/104** — unauffällig. 🔴 **Eine gleichbleibende
+   Compliance-Zahl nach dem Hinzufügen eines Geräts ist ein Befund, kein Erfolg.** Zweite
+   Voraussetzung: die Service-Accounts `nautobot`/`ha` gibt es auf einem Werksgerät nicht.
+5. **CAPsMAN verteilt keine Login-Passwörter.** Zentral sind die **WLAN-PSKs**; der Geräte-Login
+   (`/user`) ist eine lokale DB pro Gerät. Das einheitliche Admin-PW ist eine von Hand angewendete
+   Konvention.
+6. **Firewall-Regelnummern aus `print where` sind Handles, keine Positionen.** Nach `place-before`
+   zeigte die TEMP-Regel **60** neben `drop` auf **59** — lag aber davor. Beweis ist der Zähler
+   (`print stats`), nicht die Zahl.
+
+## Zwei Korrekturen an bestehender Doku
+
+- **Der Kanalplan war schon da.** TP25 hatte ihn am **2026-08-24** für genau dieses Gerät gerechnet
+  (DFS vom User genehmigt). Ich hatte ihn zunächst neu erfunden und wäre bei ch1 statt **ch6**
+  gelandet. Merkregel: den TP-Body lesen, nicht nur den Quick-Index.
+- **Der Port war `ether21`, nicht `ether22`.** Der Befund lag in den Daten: in der dynamischen
+  `pvid`-VLAN1-Zeile stand `current-untagged=…,ether21`. Gegenprobe ist
+  `/interface bridge host print where interface=etherN` — dort steht die MAC des Gegenübers.
+- **ap1 stand in Nautobot auf „Wohnzimmer Sideboard"**, physisch aber in **Technik UG**. Der
+  Eintrag war der Ziel-Standort nach dem geplanten Umzug. Korrigiert.
+
+## Dateien
+
+| Datei | Zweck |
+|---|---|
+| `routeros/tp28-ap3-phase1-erreichbar.rsc` | über die LAN-Seite: `ether1` aus WAN, Mgmt auf `vlan99` |
+| `routeros/tp28-ap3-phase2-cap.rsc` | über `vlan99`: Werks-WLAN weg, CAP-Modus, `vlan-filtering=yes` |
+| `routeros/tp28-ap3-service-accounts.rsc` | `nautobot`/`ha` + Gruppen (sonst kein GC-Backup) |
+| `routeros/tp28-ap3-werksreste.rsc` | die drei Drifts aus dem ersten Compliance-Lauf |
+| `nautobot/ingest-ap3-device.py` | DeviceType, Device, 16 Interfaces, IP, SecretsGroup |
+
+Alle vier `.rsc` tragen Platzhalter statt Secrets; die echten Dateien werden zur Laufzeit ins
+Scratchpad generiert und danach gelöscht.

docs/teilprojekte.md

@@ -70,12 +70,15 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), beide **reine CAPs** —
   `cap enabled=yes`, `discovery-interfaces=vlan99`. Die APs halten **keine eigene WLAN-Config** mehr;
   Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
-  🆕 **Dritter AP `ap3` (cAP ax) in Arbeit seit 2026-08-30** — **TP28 dafür wieder geöffnet**.
-  Core-seitig fertig: **`ether21` ist Trunk** (10/20/30/40/50/90/99 tagged, Muster `ether15`) und im
-  GC-Template nachgezogen, Compliance weiter **104/104 / 0 Drifts**. ap3 hängt bereits am Kabel und hat Strom (`link-ok`, MAC `D0:EA:11:FF:16:9D` = Label-E01),
-  der Bring-up steht aber noch aus. Ziel-IP **`10.40.99.13`**, Kanäle **`5180/Ce` + `2437`** nach dem
-  TP25-Kanalplan vom 2026-08-24. ⚠️ **ap1s Radios gehen vorher aus** (steht bis zum Umzug neben ap3);
-  ap1 kehrt später auf `5260/Ce` (DFS) zurück, ap2 auf `5300/Ce`.
+  🆕 **Dritter AP `ap3` (cAP ax) ✅ LIVE seit 2026-08-30** (TP28 dafür wieder geöffnet):
+  `10.40.99.13`, Uplink `ether1` → **core `ether21`** (Trunk), reiner CAP, **RouterOS 7.24.1**
+  (die anderen vier auf 7.24 — Angleichung ist ein eigener TP27-Durchgang). Kanäle
+  **`5180/ax/Ce/I`** + **`2437/ax`** (ch6) nach dem TP25-Plan vom 2026-08-24, am Gerät nachgemessen.
+  🔴 **ap1 ist funkstill** — es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und würde
+  auf 5180 kollidieren; es hat deshalb bewusst **keine Provisioning-Regel** am Manager, bleibt aber
+  erreichbar. Beim Umzug: ap1 → `5260/Ce` (Band B, DFS, **Frequenz-Liste statt Einzelwert**),
+  ap2 → `5300/Ce`, Uplink ap1 → `core ether3`.
+  **Compliance jetzt 130/130 / 0 Drifts über 5 Geräte** (vorher 104/104 über 4).
 - **SSDP-Relay** (TP7.1, **nachgebessert 08-25**): LXC **108 `mcast-relay`** auf pve, zweibeinig
   `10.40.10.21` (VLAN10) + `10.40.40.21` (VLAN40) — dafür trägt `core ether13` beide VLANs; mDNS macht
   weiterhin der Core. **Läuft seit 08-25 ohne `--ssdpUnicastAddr`** — die Flagge verwarf die M-SEARCH
@@ -242,7 +245,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
 > | TP24 | 🔜 | DC-USV | — |
 > | TP25 | ✅ | WLAN-Stabilisierung (Kern erledigt) | 2026-08-24 |
-> | TP28 | ⏳ | WLAN/CAPsMAN — **wieder geöffnet**: dritter AP `ap3` (cAP ax) | Kern ✅ 2026-08-18 |
+> | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
 > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
 > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
 > | TP31 | ✅ | Reverse Proxy Caddy (Schritt 1–4 ✅) | — |
@@ -1345,7 +1348,7 @@ die Redundanzfrage oben.
 
 <a id="tp28"></a>
 
-### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ⏳ **WIEDER GEÖFFNET 2026-08-30: dritter AP `ap3`**
+### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **ap3 LIVE (2026-08-30)** — wieder geöffnet und durchgezogen
 
 > **Der CAPsMAN-Kern ist und bleibt ✅ KOMPLETT (2026-08-18)** — der Abschnitt darunter ist
 > unverändert der Archivtext inkl. Post-Mortem. Wieder geöffnet wurde das TP am 2026-08-30,
@@ -1503,19 +1506,36 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört
 > Bridge-Host-Tabelle stellen.** `/interface bridge host print where interface=etherN` nennt die
 > MAC des Gegenübers — hier `D0:EA:11:FF:16:9D`, exakt die `E01` vom ap3-Label.
 
-##### Stand 2026-08-30 (diese Session)
-- ✅ Backups core+ap1 (`pre-ap3-20260830.backup`/`.rsc` auf den Geräten), Compliance-Ausgangsstand
-  **104/104, 0 Drifts**.
-- ✅ **`core ether21` ist Trunk**: tagged in 10/20/30/40/50/90/99, Muster = `ether15` (ap1).
-  `pvid=1`/`frame-types=admit-all` unverändert; das VLAN1-Bein entsteht dynamisch aus dem pvid.
-- ✅ **GC-Template nachgezogen und gepusht** (Commit `e25d654b`): `ether21` im Core-L2-Block, und
-  der AP-Zweig rendert die Bridge-Ports jetzt aus **`ap.extra_ports`** statt hartkodiert
-  `ether3/4/5`. **Compliance danach wieder 104/104, 0 Drifts** — das beweist, dass ap1/ap2
-  zeichengleich rendern.
-- ✅ Bring-up-Dateien geschrieben: [`routeros/tp28-ap3-bringup.rsc`](../routeros/tp28-ap3-bringup.rsc)
-  + [`routeros/tp28-ap3-lifeline-abbau.rsc`](../routeros/tp28-ap3-lifeline-abbau.rsc).
-- 🔜 **Offen:** physischer Bring-up (Strom + `/import`), ap1-Radios aus, CAPsMAN-Objekte für ap3,
-  Nautobot-Adoption, PW-Rotation, MikroMCP-Registry, Messrunde.
+##### Stand 2026-08-30 — ✅ DURCH
+- ✅ **`core ether21` ist Trunk** (10/20/30/40/50/90/99 tagged, Muster `ether15`), GC-Template
+  nachgezogen; AP-Zweig rendert Bridge-Ports aus **`ap.extra_ports`** statt hartkodiert.
+- ✅ **Zugang über `ap3 ether2` → `core ether22`** (Patchkabel). Über `ether1` war ap3
+  grundsätzlich nicht administrierbar, s. Gotchas unten. Loop-Schutz: `ether21` war während
+  Phase 1 abgeschaltet, danach im selben Befehl getauscht (`ether22` aus, `ether21` an).
+- ✅ **Bring-up in zwei Phasen**: Phase 1 (`ether1` aus der WAN-Liste, `10.40.99.13/24` auf
+  `vlan99`, Flotten-PW) über das Kabel, Phase 2 (Werks-WLAN weg, CAP-Modus,
+  `slaves-datapath`, `vlan-filtering=yes`) über `vlan99`.
+- ✅ **RouterOS 7.20.8 → 7.24.1 + RouterBOOT 7.24.1** (zwei Reboots, TP27-Kriterium
+  `current-firmware = upgrade-firmware`). ⚠️ Die anderen vier stehen auf **7.24**; die
+  Angleichung auf 7.24.1 ist ein eigener TP27-Durchgang (Core-Reboot = Standort-Ausfall).
+- ✅ **ap1 funkstill** (Provisioning-Regeln entfernt + `remote-cap provision`), gegengeprüft
+  **am CAP**: nur noch `wifi1`/`wifi2` mit `running=false`, keine dynamischen VAPs.
+- ✅ **ap3 funkt**: `cap-wifi5` = **`5180/ax/Ce/I`**, `cap-wifi6` = **`2437/ax`**, voller
+  VAP-Satz (2 Master + 7 Slaves), alle `running=true`.
+- ✅ **Datapath bewiesen**: 20 IOT-Clients auf ap3, Ping über VLAN30 mit **0 % Loss**.
+  *(Bewusst nicht über die Registration-Table abgenommen — die zeigte im 14-h-Ausfall
+  25 zufriedene Clients. Bei statisch reservierten Shellys erzeugt ein Roam keine neue
+  DHCP-Lease, deshalb ist hier Datenverkehr das belastbare Signal.)*
+- ✅ **Nautobot**: DeviceType `cAP ax`, Device `ap3` mit 16 Interfaces, `primary_ip4`,
+  `secrets_group`, ConfigContext (`5g=ch36 2g=ch6 extra_ports=[]`).
+  Nebenkorrektur: ap1 stand auf „Wohnzimmer Sideboard", steht aber in **Technik UG**.
+- ✅ **Compliance 130/130, 0 Drifts über 5 Geräte.** Die drei Werksreste, die der erste
+  Lauf mit ap3 gemeldet hat (defconf-DNS, 11 defconf-Firewallregeln, fehlende
+  `/ip service`-Härtung), sind mit `routeros/tp28-ap3-werksreste.rsc` abgeräumt.
+- 🔜 **Offen:** TP25-Messrunde (`bash docs/tp25-runde.sh ap3-bringup`) — braucht einen
+  Rundgang. Leitfrage: deckt ap3 allein ab, was ap1 abgedeckt hat?
+- 🔜 **Offen:** Passwort-Rotation (TP30) — das gemeinsame Admin-PW ist in dieser Session
+  verbrannt; ap3 trägt es bereits mit, hängt also in der Rotation mit drin.
 
 ##### Was am cAP ax anders ist als am hAP ax² — und was daran wehtut
 - 🔴 **Nur ZWEI Ethernet-Ports** (`ether1` PoE-in, `ether2` PoE-out) — kein `ether3/4/5`. Der