- 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>
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>
Verifiziert am VLAN1-Host (FB-nah): FB annonciert 2002::-Prefix per RA,
curl -6 klappt, ping6 Google v6 = 100% Loss (flatterhaftes 6to4).
Intern NICHT durchgereicht: Mac mini (VLAN20 hinter ap1) v6-los —
ap1 kein RA/DHCPv6-PD, Branch-Switch nicht v6-konfiguriert,
Core-Switch v6-Fähigkeit unklar. 6to4 untauglich für RT-Medien;
saubere Alt = 6in4-Tunnelbroker (HE). Geli-CGNAT-Bypass unberührt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Liwest bietet kein natives IPv6 (techn. Support bestätigt).
- Christophs 6to4-Versuch am Mac mini/LAN NICHT nutzbar (stf0 down,
keine globale v6, kein v6-Route/Internet) → kein funktionierendes
v6 auf Christophs Seite; ap1/TP4 bleibt v4-only.
- 6to4 = legacy/relay/hohe Latenz → keine Basis für Echtzeit-Medien;
saubere Alt bei Bedarf = 6in4-Tunnelbroker (HE).
- Geli-seitiger CGNAT-Bypass (ihr natives v6, Telegram-Reflector-Leg)
bleibt davon unberührt — der billige Hebel braucht Christoph-v6 nicht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- pve: Hypervisor zählt zu INFRA (User-Entscheid) → 10.40.20.100 (VLAN20),
MGMT/VLAN99 = nur noch Switch/AP-Mgmt.
- Mac mini ✅ live auf 10.40.20.167 (Omada Access-INFRA ohne VLAN1).
Kontext (live, nicht im Repo):
- Omada: Access-IOT/-UNTRUSTED/-GUEST/-MGMT Profile angelegt (Satz komplett).
- ap1 DNS: macmini.bf.lan → 10.40.20.167.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eigenständiges Arbeitspaket: finale statische IPs je Gerät in den
Ziel-VLANs (INFRA 20 / MGMT 99), Host-Oktett beibehalten, Vorschläge
zum Bestätigen.
Kontext (live in dieser Session umgesetzt, nicht im Repo):
- Omada PVID-Fix Teil 1: P3/P6 Sonos→Access-MEDIA (VLAN40),
P5 Drucker→Access-MAIN10 (VLAN10).
- ap1 srcnat: accept 10.40.0.0/16 vor Masquerade → Inter-VLAN ohne SNAT.
- Voraussetzung erfüllt: VLAN1↔VLANx-Routing via statischer FB-Route → ap1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Toolkit, um den FB-Bridge/Passthrough-Cutover (Liwest) autonom auf ap1 zu
testen, während Claude/MikroMCP offline ist (Test-Client auf install-wifi,
LAN4-Umstecken kappt den Live-Pfad).
- wan-cutover-test.rsc: wantest-probe (schichtweise Diagnose: ether1-IP,
default-gw, WAN-Reach via :resolve@1.1.1.1, DoH end-to-end) + wantest-run
(blockierender Loop, Hintergrund-fähig). Persistentes Disk-Logging nach
wan-test.0.txt.
- wan-macclone-test.rsc: CM-MAC-Clone (0C:72:74:36:90:99) mit eingebautem
Auto-Revert (~90s), scheduler-frei.
- wan-cutover-runbook.md: Solo-Runbook für den User (Console altes WiFi →
10.40.41.1).
Scheduler-frei, weil device-mode=home auf ap1 /system scheduler und /tool
fetch blockiert. Reachability via :resolve statt ping ([/ping] gibt in
7.23 nil; ICMP hier geblockt). Public-IP 86.56.201.104 bereits bewiesen
(kein Liwest-MAC-Lock).
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>
Ersetzt manuelles Referenzieren von Zusatzdateien beim Sessionstart.
HANDOVER.md als Archiv-Dokument markiert; teilprojekte.md bleibt kanonisch.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
