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>
Projekt-Skill unter .claude/skills/projektstatus/ — liest SSoT docs/teilprojekte.md
frisch, gruppiert alle TP in Themenblöcke (inkl. TP17 Shelly, TP14-Migration) und
rendert ASCII-Statusbaum + kritischen Pfad.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vw von bypass/everyone auf non_identity(Heim-IP)+allow(email:christoph) umgestellt
(reusable-Policy via App-PUT detacht). Neuer 🔴 Fund dokumentiert: Wildcard
*.emsenhuber.net login_method:github/google = jeder Eingeloggte erreicht alles
(user-gated). hass-400 = HA-Origin (nicht Access), gateway-dw WG offen. §10.6.
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>
Requirements/Architektur zur Ablösung von ALLNET-Core + 2 Branch-Switches:
Strom-Baseline, Energieeffizienz, zentrales Management, DC-USV-Konzept.
Status: Entwurf; verweist auf TP15 in teilprojekte.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 6 NAS-Origins .41→.20 repointet (ha-mcp, NAS-ssh, gitea, vw, grafana, pve-mcp), v115→v116.
- Befund: pve-Connector erreicht VLAN20 (vw 200 via Tunnel); 502 direkt nach Ingress-PUT = transient.
- grafana 502 = Container exited, kein Routing-Problem. Kein pve-Static-Route nötig.
- Stufe-4-Connector-Vantage löst sich mit pve→VLAN20 (PVID1-Cutoff).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnose der Docker-Container-Fehler nach NAS-NIC-Wechsel auf VLAN20:
- Config-Only-Macvlan-Falle (Portainer 2-Schritt, Driver=null → kein Attach)
- Macvlan-Parent ovs_eth0 exklusiv → default_external muss weg für vlan20
- default_internal (172.18) existiert nicht mehr (Range von gitea_default belegt)
RUNBOOK: IP-Mapping .41.X→.20.X (Oktett behalten), Phase-A-Teardown,
Post-Steps (ap1-DNS, CF-Ingress-Repoint, omada-Inform .20.175), CF-Access
claude-mcp-Profil-Status.
Stack-Compose-Files + Inspect-JSONs (docs/nas-vlan20/stacks/, inspect_*.json)
via .gitignore ausgeschlossen — enthalten Live-Secrets.
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>
Alle Sonos jetzt auf VLAN40 (10.40.40.0/24), IPs per MAC DHCP-reserviert.
Korrigierte IPs (Arbeitszimmer .199/.200 → .191/.192, Arc hält .199).
Discovery-Merkregel dokumentiert: iOS-App + Home Assistant = mDNS/zeroconf
(_sonos._tcp.local.) → über Repeater lösbar; macOS-Desktop-App = SSDP
(quert VLAN nicht, kein Reflector gebaut); Spotify = Cloud.
Passend zur Router-Änderung (nicht im Repo): mdns-repeat-ifaces=
vlan10,vlan20,vlan40 (vlan20 für HA ergänzt) + forward/input-Regeln
vlan20<->vlan40. HA discovert per zeroconf selbst → self-healing der IPs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Liwest hat die FritzBox dauerhaft gegen ein Arris-Kabelmodem getauscht
(2026-07-01). WAN läuft jetzt über den Core-Switch statt ether1, ap1
zieht die öffentliche Liwest-IP direkt. Telefonie entfällt.
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>
- docs/cf-tunnel-mapping.md: Single Source of Truth zur #1033-Diagnose
(bf-Tunnel = Round-Robin über 3 Connectors macmini/pve/NAS)
- mcp/cloudflare/: README + .env.example (echtes .env via mcp/.gitignore ausgeschlossen)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ursache verifiziert: 1 Tunnel, gleicher Token auf 2 Connectors (pve+nas) →
Round-robin trifft Origins, die nur von einem Host routbar sind → sporadisch #1033.
Ziel: HA-Connector-Paar in VLAN20, Origins auf 10.40.20.x, Rogues weg.
Reihenfolge: #1033 → FB-Bridge → IP-Migration. cf-mcp (Remote-OAuth) braucht
frische Session; Handoff ist self-contained mit Startschritten + Fallback.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
peer dw gesund, aber dw→BF stumm: .41-Infra hat FB-Default-GW (ap1-DHCP
auf bridge disabled) → Antworten an Spoke-Netze landen bei der FB ohne
Route → Blackhole. "Funktionierende" Gegenrichtung war WARP, nicht Tunnel.
Fix (Interim, Double-NAT): 2 Statikrouten auf der BF-FB,
10.95.10.0/24 + 10.101.0.0/24 → 10.40.41.1 (ap1). Transparent, FM mit
abgedeckt. DW ohne WARP getestet ✅. Beim Bridge-Cutover obsolet.
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>
routeros/tp3-capsman.rsc: ap1=Manager+AP (Radios lokal), ap2=CAP (Provisioning).
5 SSIDs über beide APs/Bänder mit wifi-datapath vlan-id: main(10), iot(30, nur 2,4 GHz),
media(40), untrusted(50), guest(90); infra(20)/mgmt(99) vertagt. WPA3/WPA2+3, FT auf
main+media. Passphrase als Platzhalter __TEMP_PSK__ (echter Temp-Wert in gitignored
routeros/.secrets/tp3-capsman.psk). Ersetzt capsman-flat-asbuilt/ap1-manager/ap2-cap.rsc.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
/ip/dns mdns-repeat-ifaces re-originiert mDNS vom Router (input→output),
daher unabhängig von TP5-forward. Verifikation + Rollback + offene TP5-Punkte
(forward MAIN↔MEDIA, input UDP 5353) und SSDP/IOT-Defer dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- mcp/sonos/sonos-inv.py: SSDP + ZoneGroupTopology-API, Seed-je-VLAN-Partition,
--json / --verify. Kein MCP-Container (User-Entscheid), kein Daemon, stdlib-only.
- docs/sonos-inventar.md: Bestand + Migrationsklassen.
- Kernbefund: echter WLAN-Umzug = 6 Geräte (3× One SL + HT-Bond Arc/Amp/Sub);
Schlafzimmer-Paar nur Switch-Port; Arbeitszimmer-Paar fertig. Alle S2 →
:1400/wifictrl tot → Umzug via TP3-Cutover, nicht am Gerät.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
