sshpass -p schreibt das Passwort in argv, wo es in ps und jedem argv-Trace
steht -- die Klasse, an der am 2026-08-22 das Core-Passwort verbrannt ist.
Nach gc-transaktion.py (voriger Commit) jetzt auch die fuenf unter routeros/:
SSHPASS-Env + sshpass -e.
Nachweis, gemessen statt gelesen:
- alle 13 subprocess.run mit sshpass tragen env= (per AST geprueft; ohne env
waere SSHPASS leer und alles still kaputt)
- Signaturen passen zu den Aufrufen (AST-Arity; py_compile findet das NICHT)
- echter Lauf des gepatchten Codes gegen den lebenden Core: backup-core.py
importiert, IP zur Laufzeit auf 10.40.99.1 -> "name: crs326-core", rc=0
- Passwort in argv? nein. In ps waehrend der Verbindung? nein, 40 Stichproben
- Negativkontrolle: derselbe Test mit einem Dummy-Wert ueber die alte -p-Form
-> 36 Treffer. Die Probe ist also nicht blind, das "nein" hat Aussagekraft
Mitgefixt, weil es im umgebauten Code lag: apply-core-cutover-l3.py griff in
run_silent auf ein pw zu, das dort gar nicht existierte -- jeder Fehlerfall
endete in einem NameError statt in der gedachten Meldung.
Fuer TP30 aendert das NICHTS: der Weg ist zu, der Wert bleibt verbrannt.
Posten #1 (MikroTik-admin) bleibt faellig. Im TP so hingeschrieben, damit es
niemand als erledigt liest.
--- Archivierung (Christoph-Entscheid) ---
Beim Fixen fiel auf, dass alle vier Cutover-Skripte auf tote Adressen zeigten:
apply-core-cutover-l3.py 10.40.41.211 tot (VLAN41 seit 2026-08-27 weg)
backup-core.py 10.40.41.211 tot
restore-core.py 192.168.88.1 tot (Werks-Temp-Pfad)
backup-ap1.py 10.40.10.1 ANTWORTET -- ist aber der CORE
backup-ap1.py war der gefaehrliche: er waere nicht gescheitert, er haette den
Core gesichert und die Datei ap1-pre-core-cutover-*.backup genannt. Wer das
spaeter zurueckspielt, spielt Core-Config auf einen AP.
Entscheid war archivieren, nicht reparieren -- der Cutover ist am 2026-08-08
durch, die Skripte haben ihre Aufgabe erfuellt. Sie liegen jetzt unter
routeros/archiv-tp15-cutover/ mit README nach dem Muster von switch/.
Die Pfad-Nebenwirkungen des Verschiebens sind ABSICHTLICH nicht repariert
(backup-core.py schriebe jetzt ins Archivverzeichnis, apply-core-cutover-l3.py
faende seine .rsc nicht mehr) -- sie zu reparieren hiesse, die Skripte wieder
lauffaehig zu machen, und das ist gerade nicht die Absicht.
Der sshpass-Fix wurde trotzdem VOR dem Verschieben gemacht: Archiv-Code wird
abgeschrieben, also soll dort das richtige Muster stehen.
import-core-rsc.py bleibt, wo es ist -- als einziges generisch nuetzlich. Sein
Default-Host ist ebenfalls tot (--host mitgeben), und in --host steckt ein
zweiter latenter Bug: sys.argv[1] wird als RSC-Pfad gelesen, bevor auf --host
geprueft wird. NICHT gefixt, eigene Runde.
Zeiger gesetzt in: CLAUDE.md (sshpass-Gotcha), teilprojekte.md (TP30),
teilprojekte-archiv.md (TP15), Handoff 2026-08-31.
Co-Authored-By: Claude Opus 5 <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>
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.
