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