Dritter Access-Point ap3 (MikroTik cAP ax, cAPGi-5HaxD2HaxD) kommt dazu und loest
mittelfristig ap1 in Technik UG ab. Statt eines neuen TP wandert TP28 aus dem Archiv
zurueck -- neue Regel: ein archiviertes TP ist ein geschlossenes, kein versiegeltes
Ticket (Christoph-Direktive 2026-08-30).
Live am Core:
- ether21 ist AP-Trunk (10/20/30/40/50/90/99 tagged, Muster ether15). ⚠️ Erratum: erst
war ether22 angenommen und getaggt; der Port hat keinen Link. Gegenprobe ueber die
Bridge-Host-Tabelle: auf ether21 sitzt D0:EA:11:FF:16:9D = E01 vom ap3-Label.
ether22 wieder leer.
- Backups vorher: pre-ap3-20260830.backup/.rsc auf core und ap1.
- Compliance vor und nach jeder Aenderung 104/104, 0 Drifts.
Golden Config (2 Pushes: e25d654b, 20472cdb):
- Core-L2-Block traegt ether21.
- AP-Zweig rendert die Bridge-Ports jetzt aus ap.extra_ports statt hartkodiert
ether3/4/5. Das war die stille Annahme "AP == hAP ax2 mit 5 Ports"; der cAP ax hat
zwei. Default in ap-common = hAP-ax2-Bestand, ap3 ueberschreibt mit [].
Dass ap1/ap2 danach zeichengleich rendern, beweist die 0-Drift-Messung.
Kanalplan NICHT neu erfunden: TP25 hat ihn am 2026-08-24 fuer genau dieses Geraet
gerechnet (DFS vom User genehmigt). ap3 = 5180/Ce + 2437 (ch6, nicht ch1 -- ch1 bleibt
fuer ap1, damit 1/6/11 erstmals lueckenlos aufgeht). ap1/ap2 gehen beim Umzug auf
5260/Ce bzw. 5300/Ce, 5220/Ce bleibt Ausweichspur.
MikroMCP-Registry (MCP-Lifecycle, User-Freigabe 2026-08-30) -- zwei Drifts:
- MIKROMCP_CONFIG_PATH zeigte auf ~/dev/bf-network-r6 (Archiv-Repo); die identische
Datei in bf-infra war wirkungslos. Jetzt bf-infra = SSoT.
- In opencode.jsonc fehlte MIKROMCP_CONFIG_PATH ganz, hinterlegt waren nur ap1/ap2 --
opencode kannte core/branch gar nicht. Beide Clients zeigen jetzt auf dieselbe
Registry; ap3 aufgenommen, rosVersion von stale 7.23/7.19.5 auf 7.24 korrigiert.
Neustart des MCP noetig, Registry wird nur beim Start gelesen.
Noch offen: physischer Bring-up (Datei liegt bereit), ap1-Radios aus, CAPsMAN-Objekte
fuer ap3, Nautobot-Adoption, Messrunde -- und die Passwort-Rotation: das gemeinsame
MikroTik-Admin-PW ist in dieser Session durch eine ungefilterte Ausgabe des
mikromcp-env-Blocks ins Transkript geraten und gilt als verbrannt (Posten fuer TP30).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cloudflared-Konfigurationsmaterialien fuer TP16.3 (BFF-public-Tunnel
auf dem Edge statt cloudflared-QUIC-Workaround). Enthaelt:
- ap-bootstrap.rsc: RouterOS-Script fuer ap1/ap2 (veth, srcnat,
container-mounts, env-Vars). Token kommt aus ~/.secrets, wird per
SFTP auf den Router kopiert — kein Klartext im Script.
- cloudflared-bf-public-config.yml: tunnel-UUID + credentials-Pfad
(KEIN Secret). Ingress wird CF-Dashboard-gemanagt (config_src=cloudflare).
- .gitignore: credentials.json mit dem Tunnel-Secretbase64
(PrivateKey des Tunnels, niemals committen).
Status: vorbereitet, nicht ausgefuehrt. credentials.json bleibt lokal.
