TP20: Postgres-16-LXC (105, pve, 10.40.20.20) provisioniert, UTF8/en_US.UTF-8,
wal_level=replica, DB+Rolle nautobot angelegt, End-to-End verifiziert. archive_mode
bewusst noch aus bis TP18/pgBackRest steht.
TP21: Nautobot-Stack (ghcr.io/nautobot/nautobot:3.1.7) als Portainer-Stack auf NAS
live (App+Worker+Scheduler+Redis), DB=platform-pg, API-Smoke-Test grün. Healthcheck-
gated Worker/Scheduler-Start ergänzt (Migration-Race-Condition beim Erstboot gefixt).
TP19.1: sw2 jetzt final auf 10.40.99.12 (statisch) — Christoph über Klickanleitung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TP2.1 (sw2-Standalone-Recovery) von Christoph solo abgeschlossen. TP19-Live-Sweep
auf ap1 zeigt VLAN1 schon viel weiter zurückgebaut als dokumentiert (defconf-DHCP
bereits disabled, cudy1→VLAN10 umgenutzt, cudy2 tot) → neuer Unterpunkt TP19.1 für
den VLAN99-MGMT-Cutover. TP14.1-Rest obsolet (kein Omada-Re-Adopt mehr), TP14.3
DNS-Sweep fertig (nas/docker-Records auf ap1 korrigiert, omada/omada-mcp/fritzbox-
Records entfernt, da Controller von Christoph komplett gelöscht wurde). RouterOS-
Config-Backups (enthalten Live-WiFi-Passphrasen) neu gitignored.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dirtyvader-main-Clients bekommen zeitweise VLAN1-IPs (10.40.41.x) statt
VLAN10 — gleiches Dual-DHCP-Race-Muster wie beim ap2-Fix (TP3.1,
2026-07-06), aber die admit-only-vlan-tagged-Härtung fehlt bisher auf ap1.
Zwei-Phasen-Runbook angelegt: Phase A (TP3.1-Scope, Akutfix ap1) vor
Phase B (TP19-Scope, voller VLAN1+cudy-Teardown, macht Phase A obsolet).
TP19 auf hochdringlich gesetzt, da VLAN1 jetzt ein aktiver Bug ist statt
nur Cleanup.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sw2-Controller-Link brach beim VLAN20-Umzug (TP14.1), Werks-Reset beim
Rettungsversuch, fehlerhafte Wiederherstellung — Controller-Zustand jetzt
invalid. sw2 wird ohne Managementsoftware neu aufgesetzt (TP2 als Playbook,
neue Portbelegung offen). TP15 korrigiert: Omada bekommt keine Rolle mehr,
auch nicht WLAN (bleibt bei hAP ax²/CAPsMAN) — reines MikroTik-Ecosystem.
TP19-Update: Shelly wieder da, SwitchBot-Move erst nach VLAN1-Retirement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vmbr0.20 (kaputte Netzadresse statt Host-IP) auf 10.40.20.100/24 korrigiert,
Default-GW live geflippt (ifreload -a, kein Reboot). CF-Ingress bf-pve
(pve/j44d6tua-ssh) + ap1-DNS nachgezogen; dabei Alt-Bug gefunden und gefixt
(pve-mcp.bf.lan zeigte noch auf .41.173 statt .20.173).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer TP-Konzeptstand aus der Storage-Skalierungs-Diskussion: selbst
gehosteter, geo-verteilter S3-Objektspeicher (Garage) über BF/FM/DW als
Cold-Tier — statt Cloud oder größerem Einzel-NAS.
Kernentscheide festgehalten: Engine=Garage (WAN-tolerant; Ceph/MinIO/
SeaweedFS als Fallback begründet), Disk-Layout=JBOD statt RAID
(Redundanz nur über Sites, RF=3), Variante kalt=Objektspeicher/heiß=
lokal. Inkl. Dimensionierung (10 TB nutzbar Anker), Kostenmodell
(capex/opex, per-Site + kumulativ, JBOD-vs-RAID1-Ersparnis) und Impacts
auf Syno-Rolle, Backup-Kette und Container-Hosts (TP14/15/10/16).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Entscheidung: alle Shellys bekommen statische IP (10.40.30.<octet>, gw/dns .30.1)
+ in-pool DHCP-Reservierung als Backup. set_sta auf static=true (Default) umgestellt
(Ziel-IP aus Oktett), _sta_cfg-Helper.
- pool-v30 auf .100-.250 erweitert (Reservierungen jetzt in-pool, User-Konvention).
- s24 (14:33:5c:d8:2d:7c) ins inventory/bf.csv + .30.204-Reservierung.
- Voller HA-Device-Scan (alle MAC-Geräte, nicht nur configuration_url): fand
Apple TV 4K + Philips TV (aus, VLAN40) — vor cudy-Teardown VLAN verifizieren;
Apple TV = vmtl. Thread-Border-Router (TP17.1). Tasmota bestätigt tot (MAC nicht im Netz).
- .41.246/.247 = cudy1/cudy2 (Teardown-Ziele) dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live-Abgleich Projektstatus vs. echter Netzstand (MikroMCP/pve-mcp/HA):
- VLAN20 verifiziert: NAS .20.10, Mac mini .20.167, pve-LXC .20.126 alle live;
einziger Host noch in VLAN1 = pve-Host-Mgmt .41.100 (verbleibende Host-Migration).
- TP17 Shelly: Migration schon ~6/26 durch (s14/16/18/22/23/24 stabil auf .30.2xx);
16 VLAN1-Shellys verbleiben; alle VLAN30-Reservierungen stehen; s6-Reservierung
.30.213 MAC gefixt (0C:72..9E -> real D0:CF:13:D8:18:FC).
- HA-Cross-Check aller IPv4-Geräte: .30.204 = Shelly Bad/Spiegelschrank (=vmtl. s24);
Nicht-Shelly-VLAN30-Mover SwitchBot/.184 + Tasmota Nous A1 + 1 offen; .41.246 unident.
- Neues Runbook docs/tp17-shelly-go-runbook.md: 16er-Migrationstabelle, Go-Sequenz,
Scope-Erweiterung (WLAN+IP+einheitliches Geräte-PW via Shelly.SetAuth),
Gen4->Thread/Matter-Projektion (TP17.1, experimentell), VLAN1-Leerstand-Verdikt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root-Cause endgültig (User-Diagnose bestätigt): ein cloudflared ist blind NUR
für macvlan/ipvlan-Container auf seinem EIGENEN Host → mehrere Connectoren auf
1 Tunnel + Round-Robin = 1/N garantierte 1033 ("jeden 3. Schuss eine Niete").
Kein Route→Connector-Pinning innerhalb eines Tunnels → HA nur über getrennte
Tunnel: reziprokes Per-Host-Design (jeder Dienst von den anderen Hosts bedient,
3 Tunnel/2 cloudflared je Host = voll HA gegen Single-Host-Ausfall).
- cf-tunnel-mapping.md §9: Invariante + Live-Inventory v119 (Access-Modi,
DOWN-Origins pbs/nginx-bf/hermes×2) + Ziel-Design + Umsetzungsreihenfolge;
Abschnitte 1-8 als Historie markiert.
- teilprojekte.md TP16 umgeschrieben: Root-Cause, reziprokes HA, Access-Strang
(hass-400=CF-Access→WARP, vw=bypass→schützen), Status "dokumentiert,
Umsetzung = eigene Session".
- Reine Doku, keine Tunnel-/DNS-/Container-Änderung.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- pve-mcp „Failed to connect" = mcp-pve 0.4.8 kann nur 1 MCP-Session
("Server already initialized") → Upgrade 0.6.1 (Per-Session), ✔ Connected.
omada-mcp war/ist gesund (frische Session-ID pro Init).
- Kollateral: VLAN20-Host-DNS auf NAS+LXC zeigte noch auf totes .41.254
→ docker-pull scheitert; LXC pct set .20.1, NAS Synology-DHCP-DNS-Falle.
Neuer Gotcha in CLAUDE.md.
- TP16 (neu, hochdringlich): FQDNs via CF „sehr unsicher" = #1033-Round-Robin
zurück; Live-Snapshot 2026-07-10: bf-Tunnel 2 statt 3 Connectoren, alle
frisch (2026.7.1), Origins nach VLAN20-Move erneut asymmetrisch zu auditieren.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TP3.2 = P750W/Discovery erledigt; offene Coverage-Kur (Dead-Spot-Map →
Platzierung/3.AP/Outdoor, Nachbar-Kanal-Scan, INFRA-auf-ap1) als
kaltstart-taugliches TP3.3 für die Fortsetzungs-Session ausgelagert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
macOS-Desktop-Sonos-App braucht SSDP über VLAN-Grenze; iOS/HA reichen für den
Alltag nicht, sobald der User die Desktop-App nutzen will. Reflector-Container
auf NAS/pve (nicht am hAP), Scope vlan10↔vlan40.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause: ap2 (CAP, local forwarding) hatte bridge vlan-filtering=no →
datapath.vlan-id wurde nie getaggt → alle WLAN-Clients (main/media/iot/…)
egressten ungetaggt in VLAN1 → OG-iPhone-Drops beim Roaming ap1↔ap2.
Fix wie ap1: VLAN1 untagged=bridge,ether2 (Mgmt), 10/30/40/50/90 tagged
auf ether2 + wifi1/wifi2 als tagged-Member (nur Master-Radios sind
Bridge-Ports, CAPsMAN legt das auf dem CAP nicht an). As-built +
teilprojekte.md TP3.1 + CLAUDE.md-Gotcha. OG-Funktionstest offen (User).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24
renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt.
End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247,
echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT.
Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate
an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Entscheidung: TP10 nicht mehr als Parallel-Migration vorab, sondern zusammen
mit dem permanenten FB-Bridge-Cutover. Grund: VPN-auf-FB und FB-Bridge
schließen sich aus (Bridge = Modem = keine VPN-Terminierung) -> Migration muss
am Bridge-Tag passieren; dann hat ap1 die echte Public-IP -> kein
Port-Forward-Umweg, Spokes zeigen direkt auf ap1/DDNS. FM-PoC hat den
WG-Spoke-Fix bewiesen (de-risked).
Park-Zustand ap1: Peers disabled, WG-Routen entfernt (FM/DW wieder über die FB),
wg-hub bleibt (Key erhalten), Firewall bleibt (TP5-Vorarbeit). Beide VPN vorerst
über die FB: FM=IPsec, DW=FB-WG. Resume = Bridge-Tag (Klickanleitung,
FB-LAN-IP als Interface-Address).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Gelis CGNAT ist nur v4 → ihre FB über natives v6 erreichbar (Port offen).
WARP (schon im Einsatz) liefert Christoph outbound-v6 trotz Liwest-v4-only.
- PoC = ad-hoc Fernwartung; Daueform = direktes WG ap1↔Geli-FB über echtes
v6 (HE-6in4, da Liwest auch mit Fiber kein v6) statt Hub-Spoke-Gymnastik.
- Endgeräte (Note10, Cudy) bleiben v6-agnostisch: v6 nur äußerer Transport,
LAN bleibt IPv4. Nicht für Telefonie.
- teilprojekte.md: TP10 von ⏸ PAUSIERT auf 🅿️ VERTAGT (Bridge-Cutover-Bündelung).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.
- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.
Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Variante A (BIND/RFC2136) verworfen: HW-Vorgabe "Container nur am Router
oder gar nicht, keine NAS/pve-Abhaengigkeit" + hAP kann praktikabel keinen
DNS-Container hosten (live: ~90MB frei, kein USB, Flash-Wear).
- research-Doc umgeschrieben: Entscheidung + Variante A als parkierter Anhang
- teilprojekte TP4 auf finale Entscheidung
- technitium/ -> dns/ umbenannt + README
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
