ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript
tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur
benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS =
Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per
!security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert.
Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280,
ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder
aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance ->
140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed.
Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder
sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das Skript endete bisher mit `vlan-filtering=yes` und einer Log-Zeile -- ohne
jede Pruefung, ob der CAP wirklich CAP geworden ist.
Neu, Punkt (6) VOR dem Scharfschalten: das Skript zaehlt seine eigenen
wifi-Objekte und schreibt das Ergebnis per `:log info`. Bewusst nicht `:put`
und bewusst nicht danach -- nach `vlan-filtering=yes` kann die Sitzung
abreissen, eine Konsolenausgabe waere dann verloren. Das Log ueberlebt und
ist ueber `/log print where message~"tp28-ap3"` nachlesbar.
Sollwerte am Geraet gemessen, nicht angenommen (ap3 live, 2026-08-30):
security=0 configuration=0 channel=0 datapath=1 radios-mit-manager=2
🔴 Erwartet ist ausdruecklich NICHT "alles 0": datapath MUSS 1 sein
(dp-caps-slaves). Ein CAP mit 0 Datapaths ist der 14-Stunden-Ausfall vom
2026-08-18 -- Clients assoziieren und bekommen nie DHCP.
security/configuration/channel=0 ist der harte Beleg, dass die Werks-Inline-
Overrides weg sind: CAPsMAN haelt die Credentials, das Geraet haelt nichts.
Gegenprobe am Bestand: ap2 zeigt dieselben 0/0.
Dazu ein Abnahmeblock am Dateiende mit dem Schritt, der sich nicht im Skript
pruefen laesst: `/interface wifi radio print` AM MANAGER muss zwei Zeilen mit
CAP ap3@... zeigen (live: cap-wifi5 + cap-wifi6). Ohne diesen Schritt ist die
Abnahme wertlos, denn `remote-cap print` meldet state=Ok schon beim blossen
Verbinden -- ap1 steht seit 2026-08-30 genau so da: verbunden, gelistet, und
trotzdem funkstill, weil keine Provisioning-Regel matcht.
Am Geraet gegengeprueft: RouterOS kennt KEINEN ternaeren Operator, `a ? b : c`
ist ein syntax error. Verdikt laeuft deshalb ueber :if/:set. Der komplette
Block wurde am ap3 mit :put durchlaufen und meldet "=> OK".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
tp28-ap3-bringup.rsc + tp28-ap3-lifeline-abbau.rsc ersetzt durch
tp28-ap3-phase1-erreichbar.rsc + tp28-ap3-phase2-cap.rsc.
Der Schnitt liegt dort, wo der Zugangsweg wechselt:
- Phase 1 laeuft ueber das Werks-WLAN MikroTik-FF169F und fasst das WLAN
bewusst NICHT an -- wer dort WLAN-Objekte abraeumt, saegt den Ast ab, auf
dem die Sitzung sitzt. Sie macht ap3 auf 10.40.99.13/24 (vlan99) erreichbar.
- Phase 2 laeuft ueber vlan99, weil dort das Werks-WLAN stirbt. Sie macht aus
dem Standalone-Werksgeraet einen reinen CAP und schaltet vlan-filtering
ZULETZT scharf.
Grund fuer die Teilung, live gemessen ueber crs326-core ether21: am Werks-
cAP-ax steht ether1 in der Interface-Liste WAN. Folge -- Discovery aus (kein
MNDP/CDP/LLDP, unsichtbar in /ip neighbor), Input-TCP zu (22/80/8291/8728),
aber ICMP erlaubt. Das Geraet PINGT also und wird leicht als "erreichbar"
fehlgelesen. Die WAN-Listen-Mitgliedschaft faellt deshalb als erste Zeile.
Nebenbefund im Kopf festgehalten: ein DHCP-Lease blieb auf `offered` und ARP
auf `failed`, weil der Port in der TAGGED-Liste von VLAN99 stand -- pvid=99
regelt nur den Eingang, die Antwort ging getaggt raus, und das versteht ein
Werksgeraet nicht. Merkregel: pvid ist Ingress, tagged/untagged ist Egress.
Der Lifeline-Abbau braucht keine eigene Datei mehr: ether2 (PoE-out, haengt
nichts) wird in Phase 2 aus der Bridge genommen und abgeschaltet, wie ap1/ap2
es mit ihrem PoE-Port halten.
Kein Secret in den Dateien: das admin-Passwort steht als Platzhalter
__ADMIN_PW__ und wird zur Laufzeit aus ~/.secrets/ap3-factory.env gezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
