Kontextkommentar ueber der sec-main-Zeile dokumentierte noch den 09-04-Entscheid
(ft=no); nach der Ruecknahme am 09-14 konsistent gemacht (Entscheid-Historie bleibt
als Zeile erhalten).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Go Christoph 2026-09-14 nach Terrasse-In-situ-Session: mit ft=no ist jeder
Roam eine Voll-Reassoziation -- darin starben 2 Anrufe.
- Known-Good-Stand vor Hebel-2: Fund-E-Abschlussmessung 09-02 lief auf
ft=yes/ft-over-ds=yes + 7.24.1 ruhig (4 reauth/8,6 h, 0 Ausfaelle).
- Template [6c]-Kommentar auf Stand 09-14 gebracht: signal-range-Boden
geprueft und gescheitert (kein band-Property, cap-wifiN-Rejoin-Falle).
- Commands-File docs/transaktionen/TP25-ft-yes-secmain.commands.rsc fuer
den GC-Deploy via gc-manual-plan.py (Dry-Run gelesen).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler
existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die
"2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring)
war nie real; beide korrigiert.
Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device"
enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS,
täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5
Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit.
Announcement-Eintrag ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Legt die fünf TP36-Live-CustomFields (grouping TP36-Live) auf dcim.device an
und befüllt sie für alle 5 RouterOS-Geräte (ap1/2/3, crs326-branch/core)
ausschließlich aus Nautobot/Golden-Config — kein Geräte-Kontakt:
ros_version 7.24.1 (flotte), compliance_pct 100, dhcp_server_count
(core 7, Rest 0), dns_upstream_mode (core doh, Rest plain), mgmt_ip.
Idempotent (get-or-create CF, PATCH Device), Dry-Run default, --commit schreibt.
Token aus gitignored 210-nautobot.yml, Backup-Text nur intern geparst (nie ausgegeben).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nautobot/tp44-ipam-prefixes.py — idempotenter get-or-create für
10.40.0.0/16 (container, Route bf-core-mesh) und 10.101.0.0/24
(network, Route fm.emsenhuber.net). Dry-Run default, --commit schreibt.
Nach dem Anlegen zieht tp44-cf-estate-seed.py Schritt [7] die zwei
cloud-network-prefix-assignments automatisch ein. Muster:
ingest-baseline.py / tp37-substrat-seed.py. Noch nicht gegen Nautobot
ausgeführt (nur Dry-Run verifiziert).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fehlende exponierte Dienste ergänzt (RaspberryMatic 80/443/2001/2010,
iob-master 8081, z2m25 8080). Jeder Port per Socket-Probe belegt (nicht
aus Doku geraten); nc -z lieferte falsch-negativ und wurde verworfen.
iob-exposed/iob_slave bewusst ohne Service (kein Port gefunden).
Nautobot: 20 -> 26 ipam.Services, idempotent. Compliance 140/140.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Session lief auf veralteten Annahmen (Hostname terpene.* statt 420.*, zweiter
CF-Token erfunden) — entgegen dem User-Constraint "raten verboten". 420.teilzeitladen.xyz
ist ein Cloudflare-Worker (Projekt blaueblueten), nicht ein Caddy-Backend; :8890 gehoert
zu terpene.* via Tunnel bf-mm. Caddyfile war netto unveraendert, nur die beiden neuen
Skripte werden entfernt. Live LXC 130 ist bereits Baseline (e96fca5), Nautobot fuer TP34
unberuehrt (nur Dry-Run). Uebergabe: ~/.claude/plans/tp37-p2-seeden-dienste-silly-lerdorf.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- caddy/Caddyfile: Hostname 420.teilzeitladen.xyz (nicht terpene.*); eigener
per-site tls-Block mit CF_DNS_API_TOKEN_TEILZEITLADEN, damit der enge
emsenhuber.net-ACME-Token unangetastet bleibt (Least-Privilege)
- nautobot/tp34-caddy-cf-seed.py: veraltete terpene.*-Referenz im Kommentar korrigiert
Deploy erst nach Hinterlegen des teilzeitladen.xyz-Tokens in /etc/caddy/caddy.env
(Zone:DNS:Edit nur teilzeitladen.xyz).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Hebel 2 (ft=no) doch gezogen: sec-main von ft=yes ft-over-ds=yes auf
ft=no ft-over-ds=no. Template (nautobot/mikrotik_routeros.j2) + Push nach
bf-golden-config + Nautobot-Sync; wifi-security damit gruen (Live stand
schon auf ft=no, das Template war der Drift).
Doku nachgezogen (CLAUDE.md Punkt 5, teilprojekte.md Ist-Stand/Quick-Index/
Fund-E-Block): Soll ft=yes ft-over-ds=yes -> ft=no ft-over-ds=no, 802.11r aus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Sideboard-Test fuer ap1 (TP28) plus Umsetzung des TP25-Kanalplans
in einem Zug am Manager (crs326-core):
L2 (TEST-ether3-trunk-ap1-sideboard-2, bridge-vlan, committed):
- ether3 zum AP-Trunk fuer ap1 hinzugefuegt (analog ether15/ether21)
- Template mikrotik_routeros.j2 nachgezogen: ether3 in allen VLAN-Zeilen
WLAN (TP25-kanalplan-ap1-live, wifi-channel, OFFEN bis 2026-09-10):
- ch-5g-ap1: 5180 -> Frequenz-Liste 5260,5280 (DFS Band B, ch52/56)
- ch-5g-ap2: 5220 -> Frequenz-Liste 5300,5320 (DFS Band B, ch60/64)
- Neue Provisioning-Regeln fuer ap1 (radio-mac E5=5G, E6=2G), analog ap2/ap3
- remote-cap provision fuer ap1 und ap2
Live-Ergebnis (35 Clients an der Registration-Table, vorher 30):
- ap1: 5260/5280 + 2412 (ch1), 9/9 Interfaces up
- ap2: 5300/5320 + 2462 (ch11), 9/9 up
- ap3: 5180 + 2437 (ch6), unveraendert
- Keine 5-GHz-Kollisionen mehr, 2,4-GHz sauber auf ch1/6/11
Follow-up in naechster Session: In-situ-Messungen an den Aufstellorten;
bei ok Template auf Frequenz-Listen + ap1-Provisioning-Regeln erweitern
und die offene Akte committen. Snapshot fuer Rollback liegt bereit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
(A) DHCP-Search-Domain der 7 Netze emsenhuber.net -> bf.emsenhuber.net ueber
die GC-Pipeline (kein Direkt-Write): Template Z.133 gehoben, per
push-gc-template.py ins bf-golden-config-Repo (7a4068c4), GitRepo-Sync,
neuer manueller Job tp42-dhcp-domain in gc-configplan.py (set [find], weil
add das existierende Netz doppeln wuerde), Deploy an crs326-core.
Live 7/7 = bf.emsenhuber.net, Compliance 140/140 keine Drifts.
Nebenbefund: Remote-GC-Template hing dem lokalen hinterher (noch *.bf.lan +
router.lan) -> mit an den Live-Stand angeglichen.
Loest den Kernkonflikt: DHCP verteilte bare emsenhuber.net, Records leben
unter bf.emsenhuber.net -> bare macmini loest jetzt beim Lease-Renew.
(B) .16 (adguard_bf1) abgebaut: lag im mit FM geteilten Portainer-Stack 195
zusammen mit adguard_fm2 (.17, Standort FM). Statt Stack-Delete die compose
auf nur .17 getrimmt + redeployt (Prune). .16 weg, .17 laeuft (kurzer Blip).
Nautobot-Soll (Scope 4) an TP37 gekoppelt, separat.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
veth / ip address / ip firewall nat der drei cloudflared-Connectoren standen seit
der Vor-Ort-Session per Direkt-Write am Geraet (Runbook §3.4), waehrend /ip address
und /ip firewall unter GC-Drift-Kontrolle stehen: sechs extra-Drifts, Compliance
128/135. Sie sind inhaltlich richtig und sollen DAUERHAFT gelten -- deshalb ins
Template und nicht in eine gc-transaktion (die ist fuer befristete Versuche).
Kein Re-Baseline, kein Rueckbau, keine Zeile aufs Geraet: nur die SoT nachgezogen.
Neu ist die 28. ComplianceRule interface-veth. Vorher gab es fuer /interface veth
keine Regel -- das tragende Stueck des ganzen Aufbaus haette geloescht werden
koennen, ohne dass irgendetwas meldet.
Zwei Funde:
(a) Der veth-Export traegt zwei geraetevergebene MACs (mac-address,
container-mac-address), auf jedem AP anders. Eine nackte Regel haette damit
Dauer-Drift auf allen drei APs erzeugt, also genau die immer-rote Zahl, die
niemand mehr liest. Zwei eng auf die veth-Zeile verankerte ConfigReplace-Regeln
normalisieren sie im Backup (Lookbehind haelt container-mac-address heraus,
[^\n]*? haelt die Regel in der Zeile; Selbsttest mit Negativfaellen im Skript).
Bewusst mit der vorhandenen Maske <<REDACTED>> statt einer eigenen: sie ist im
Repo zugleich die Push-Sperre (gc-configplan.py verweigert config_set damit) --
eine Zeile mac-address=<<...>> darf nie aufs Geraet.
Kostet Backup-Treue: die veth-MACs stehen in bf-golden-config nicht mehr im
Klartext. Vertretbar, RouterOS vergibt sie beim Neuanlegen ohnehin neu.
Verworfene Alternative: MACs je Geraet modellieren -- widerspricht der
Begruendung, die fuer die VAP-MACs schon im ConfigContext-Skript steht.
(b) Der erste Compliance-Lauf meldete SUCCESS und war trotzdem unvollstaendig:
139 statt 140 Eintraege, crs326-core/interface-veth fehlte, im Job-Log
"RENDER COMPLIANCE TASK GROUP failed: Broken pipe". Zweiter Lauf sauber.
Merkregel im Runbook (Falle 16): Abnahme ist die ANZAHL der Eintraege
(Regeln x Geraete), nicht die Konformitaetsquote.
Stand danach: 139/140. Uebrig bleibt genau crs326-core/wifi-security -- die offene
Transaktion TP25-fund-e-ft-over-ds einer laufenden Messung, die bleiben muss.
Ausserdem: frischer Ingress-Snapshot von bf-public vor §5 und das geschaerfte
§5.1-Erfolgskriterium (200 mit leerem Body + server: Caddy = Strecke bewiesen,
404 = Ingress-Regel fehlt) -- am Live-System gemessen, nicht angenommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Hebel, sonst nichts. 2026-08-31 08:09 am Manager crs326-core:
/interface wifi security set [find name="sec-main"] ft-over-ds=no
/interface wifi capsman remote-cap provision [find]
ft=yes bleibt -- FT laeuft weiter over-the-air, nur nicht mehr over-the-DS.
Nimmt exakt die Aenderung vom 2026-08-17 zurueck.
Abnahme (Lease, nicht Registration-Table):
- Manager, alle vier aktiven Master-VAPs cap-wifi3/4/5/6: ft=true ft-over-ds=false
- alle 3 CAPs state=Ok, alle VAPs running=yes AM CAP gelesen
- iPhone nach 71 s zurueck auf dirtyvader-main, frische Lease 10.40.10.196,
auth-type=ft-wpa3-psk, -54 dBm; 30 Clients gesamt zurueck
- Log 08:13:20 zeigt sauberes "roamed to" zwischen zwei APs -> Roaming intakt
- Geraete-Backup vorher: pre-tp25-funde-ftoverds.backup
Governance: Transaktion TP25-fund-e-ft-over-ds OFFEN (Scope wifi-security,
Ablauf 2026-09-03). Compliance steht deshalb ABSICHTLICH auf 134/135; der Diff
ist exakt ft-over-ds=yes->no, kein Kollateral-Drift durch die Re-Provisionierung.
Das GC-Template wird erst beim COMMIT nachgezogen -- vorher gruen machen wuerde
den laufenden Versuch unsichtbar machen, und gc-transaktion.py verweigert den
Commit ohnehin, solange der Scope driftet. 135/135 kommt nach der Messung zurueck.
Messstand nach 25 min: weiter 93, letzter reauthenticating 07:34:43 (vor dem
Eingriff). Logging nachweislich lebendig (593 wireless-Zeilen heute, beide SSIDs).
Noch kein Ergebnis, nur ein sauberer Schnitt.
Drei Funde:
- cap-wifiN-Karte hat sich beim Re-Provisionieren VERSCHOBEN: ap2 war 1/2 ->
jetzt 3/5, ap3 war 5/6 -> jetzt 4/6, ap1 hat 1/2 bekommen. Wer die 07:xx-Zeilen
gegen die neuen liest, ordnet dem falschen AP zu.
- Korrektur am Vormittagsbefund: main unterscheidet sich in ZWEI Attributen, nicht
einem -- es ist auch die einzige SSID ohne wpa2-psk. Die Kontrollgruppe trennt FT
und WPA3-only nicht. Wenn Hebel 1 und 2 beide nichts bewegen, ist
authentication-types der naechste Kandidat, NICHT signal-range.
- gc-transaktion.py rief sshpass -p auf (Passwort in argv, Klasse vom 2026-08-22).
Auf SSHPASS-Env + -e umgestellt, weil das Skript laufen musste. Fuenf weitere
Dateien unter routeros/ haben dasselbe Muster und sind bewusst NICHT angefasst
(Stop-Bedingung; gehoert zu TP30). Entwarnung: /export auf 7.24 gibt Passphrasen
gar nicht aus (live geprueft), die Transaktionsakte im Git ist sauber.
Nebenbei: .gitignore hatte docs/nas-vlan20/stacks/ MIT Schraegstrich -- im Worktree
liegt dort ein Symlink auf den Haupt-Checkout, der war damit nicht ignoriert.
Doku an allen drei Stellen nachgezogen (Quick-Index, TP25-Abschnitt, Ist-Stand-Block)
plus CLAUDE.md-Pflichtlektuere und neuer Handoff mit Entscheidungstabelle fuer 09-01.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auslöser war eine unabhaengige Meldung: seit Tagen/Wochen verliert das iPhone den
WiFi-Link bei gutem Signal und landet auf Mobilfunk. Auf Mobilfunk zu fallen ist KEIN
Roaming-Problem -- bei schlechtem Roaming bliebe das Telefon im WLAN und waere nur
langsam. Es heisst, die Assoziation ist gestorben und die Neuanmeldung gescheitert.
Der Manager-Log zeigt dasselbe iPhone (F2:62:4C:E1:AF:09) mit 16 Bandwechseln in 20
Minuten zwischen ap3s 5-GHz- und 2,4-GHz-Radio, zweimal im Abstand von einer Sekunde,
bei -53..-81 dBm -- kurz darauf dasselbe an ap2. Also nicht ap3-spezifisch.
Das stand schon im Repo: TP25 Fund E beschreibt es seit dem 2026-08-20, mit derselben
MAC und der Zeile "disconnected, not responding, signal strength -47" -- Abbruch bei
ausgezeichnetem Signal. Fund E war zurueckgestellt mit der Auflage "erst wieder
aufgreifen, wenn ein Sticky-Fall erneut gemessen ist". Die ist eingetreten. Das ist
heute der zweite Fall (nach dem TP25-Kanalplan fuer ap3), in dem eine fertige Analyse
im TP-Body stand und ich sie erst nach einer Extrarunde gefunden habe.
Der eigentliche Mangel war aber die Beweislage: `wireless` lief NUR nach action=memory,
nur `firewall` ging in den Kollektor. Der Ringpuffer fasste 75 Zeilen und war von einer
Stunde ap3-Arbeit fast ueberschrieben -- rueckwirkend war nichts diagnostizierbar.
Jetzt: zwei Regeln am Core (topics=wireless und topics=caps) in denselben Kollektor wie
TP5 (10.40.20.18:514). Gegenprobe auf beiden Seiten -- 32 Zeilen liegen bereits im
Tagesfile, inkl. `associated` (debug) und `connected` (info).
Und unter Drift-Kontrolle, denn /system logging stand unter KEINER der 26 Rules und gar
nicht im Template: neue ComplianceFeature/Rule `system-logging` (Muster: TP6 /queue,
TP26 /ip firewall filter), Template-Block [6a2] nur im Core-Zweig -- RouterOS exportiert
Defaults nicht, auf ap1/ap2/ap3/branch sind Soll und Ist beide leer.
Compliance 130/130 -> 135/135, 0 Drifts. Die Zahl MUSS sich bewegen: eine
gleichbleibende Zahl nach dem Hinzufuegen einer Regel waere ein Befund, kein Erfolg.
Zwei RouterOS-Fallen, beide als Gotcha in CLAUDE.md:
- Der Topic heisst `wireless`, NICHT `wifi` -- auch auf dem neuen wifi-qcom-Stack.
Ein geratenes topics=wifi waere wirkungslos geblieben.
- RouterOS UND-verknuepft Topics innerhalb EINER Regel (`info,!firewall` = info UND
NICHT firewall). `topics=wireless,caps` haette NICHTS gematcht -> zwei Regeln.
Recherche-Ergebnis gegen die offizielle MikroTik-Doku, das meine eigene erste Hypothese
widerlegt: transition-threshold steht per Default auf -80 dBm (-time 10s,
-request-period 30s, -count 3), und unsere Steering-Objekte setzen davon nichts. Bei
-53..-74 dBm wird das iPhone gar nicht Transition-Kandidat -- unsolicited BTM scheidet
als Treiber weitgehend aus. Die vielzitierte WPA3/802.11r-Inkompatibilitaet steht NICHT
in der Doku (dort nur: FT geht nicht ueber OWE); sie bleibt Hypothese.
BEWUSST NICHT geaendert: kein einziger Funk-Parameter. Drei Hebel sind dokumentiert und
priorisiert -- (1) 2g-probe-delay=yes, kann keinen Client stranden lassen, (2)
ft-over-ds=no, nimmt die Aenderung vom 2026-08-17 zurueck, (3) signal-range-Boden, der
invasivste und einzige, der Clients aussperren kann. Einzeln, je als Transaktion, erst
mit Daten.
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>
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>
- adguard/AdGuardHome.yaml: AGH-Wizard-Setup (27 Rewrites ohne .bf, DoH zum CF-Gateway, conditional emsenhuber.net).
- nautobot/mikrotik_routeros.j2: DHCP dns-server=10.40.20.36,.37, domain=emsenhuber.net.
- docs/transaktionen/TP23-agh-firewall.commands.rsc: TP5-E2 LAN->AGH dns auf .16/.17 ersetzt durch .36/.37.
- docs/transaktionen/TP23-agh-dhcp-cutover.commands.rsc: DHCP-Cutover (dns-server + domain in einem Deploy).
Compliance 104/104, 0 Drifts. Core bleibt als Rückfallebene unangetastet.
[KEIN go fuer den Rest: Persistenz (CLAUDE.md/memory), Host.Naming (.host.emsenhuber.net),
add-dns-entries-Suffix, conditional-Upstream, lease-time-Transaktion, TP31-defer — alles im Plan,
Wartet auf separates go des Users.]
