Files

Christoph Emsenhuber 1006f91e6a 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>

2026-08-30 17:54:07 +02:00

5.5 KiB

Raw Permalink Blame History

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

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?
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.
MikroMCP-Neustart — Registry (jetzt bf-infra, mit ap3) wird nur beim Start gelesen.
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.
Kabel ap3 ether2 → core ether22 kann raus. Seit Phase 2 ist ether2 kein Bridge-Port mehr, das Kabel ist inert.
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

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

5.5 KiB Raw Permalink Blame History