admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
214 Commits 5 Branches 0 Tags
e8f7f809b03cb67a0c1bcd148b27514e4cb35290
Commit Graph

135 Commits

Author SHA1 Message Date
Christoph Emsenhuber
a969efbe6d docs 📄 pve-mcp Single-Session-Fix (TP14.2a) + TP16 CF-Tunnel 🔴 hochdringlich 
- 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>
 2026-07-10 18:29:25 +02:00
Christoph Emsenhuber
7636ea399f docs 📄 TP14.2 ✅ pve-Docker-LXC (400) → VLAN20 (#1033 gelöst) 
LXC 400 `docker` net0 tag=20/.20.126; Docker vlan20=ipvlan parent=veth20.
omada-mcp .20.176 (OMADA_BASE_URL→.20.175), adguard .20.16/.17 — running/reachable.
CF-Connector db713b30 jetzt VLAN20 → #1033-Zielbild (Tunnel healthy; portainer/gitea/vw 200).
Refs .41→.20: mcp/portainer/.env, ~/.claude.json omada-mcp, CLAUDE.md, ip-plan, cf-tunnel-mapping.

Gotchas: Proxmox-Token kein VM.Config.Network (Retag via UI); Iface heißt veth20 nicht eth0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 13:34:29 +02:00
Christoph Emsenhuber
be85403d2f docs 📄 TP14.1: Omada-Inform/sw2 vertagt (Controller-Login .20.175 fehlt) 
Login an der Controller-UI https://10.40.20.175:8043 schlägt fehl →
Inform-Adresse + sw2 re-adopt verschoben. Unkritisch: sw2 „Disconnected"
ist reiner Mgmt-Loss (Easy-Managed switcht mit letzter Config weiter,
Netz läuft). Voraussetzung fürs Nachholen = Controller-Login/Passwort-
Recovery (Creds nicht lokal hinterlegt).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 12:48:27 +02:00
Christoph Emsenhuber
7f1871eb96 docs 📄 TP14.1 ✅ NAS-Container auf VLAN20 + pve-mcp neu (Session A durch) 
Alle ep14-Container via Portainer-Stack-Redeploy auf vlan20/.20.x (Env
preserved, Volumes intakt): prometheus/node-exporter/grafana, hms-mqtt,
dashboard-web, qdrant, gitea (DB .20.23 ✓), drawio (intern), oc-charlie,
oc-johnny2. pve-mcp NEU als Stack id 202 (.20.173) — StreamableHTTP am
Root-Pfad / (nicht /sse); ~/.claude.json mcpServers.pve-mcp neu angelegt.

Geflaggt (pre-existing, nicht migrationsbedingt): alertmanager crash-loop
(${TELEGRAM_CHAT_ID}-Literal), openclaw shared-DB .41.122 down. Gotcha:
gitea-Stack hatte vlan20-Block auskommentiert → Fix via Disk-Override.
Merke: kein Blanket-Env-.41→.20 (Mac-mini .167 bleibt .41).

OFFEN: Omada-Inform-Adresse → .20.175 (Controller-UI-Task; sw2 static IP,
kein DHCP-138; nur Mgmt-Loss, Netz läuft).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 10:47:07 +02:00
Christoph Emsenhuber
5bed507d30 docs 📄 TP14 in Sub-TPs gegliedert (TP14.1–14.5 = Sessions A–E) 
- teilprojekte.md: TP14 Parent (✅ NAS + CF-Ingress) + Sub-TPs TP14.1 (NAS-Rest),
  14.2 (pve-LXC/ipvlan), 14.3 (dormante Stacks + DNS-Sweep), 14.4 (CF-Access-Profil),
  14.5 (Freigabe-Gate → TP5). Analog zu TP3.1/3.2-Muster.
- Handoff-README-Headings auf TP14.x-Nummern gezogen (Konsistenz).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 10:08:52 +02:00
Christoph Emsenhuber
c51704fd84 docs 📄 TP14 angelegt: Host/Container-IP-Migration VLAN1→VLAN20 (NAS ✅, pve 🔜) 
- teilprojekte.md: neuer TP14 (Docker-Cutover NAS+pve) + Querverweise TP11 (Track-B/C) + Reihenfolge #3.
- NAS ep14 ✅ auf vlan20-Macvlan; CF-Ingress v116; Root-Cause Config-Only-Macvlan-Falle dokumentiert.
- Handoff docs/nas-vlan20/handoff/README.md: paste-fertige Anschlussstatements Session A–E
  (sequenzielle Sessions, keine parallelen Branches — geteilte Live-Infra).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 09:46:59 +02:00
Christoph Emsenhuber
711b46f92c docs 📄 TP5.1: DNS-Redirect + Live-Torch für Low-Trust-Geräte (Airfryer-Fall) 
Airfryer-Override dns=1.1.1.1 (public Consumer-Resolver, ≠ Gateway-DoH) macht
das Gerät DNS-blind + umgeht Filterung. Zwei Folgepunkte vorgemerkt:
- (a) DNS-Redirect (dst-nat 53 auf plain Resolver) = dauerhafter Fix, Logging+OTA
- (b) Live-Torch als Ad-hoc-Flow-Observability
Verweis in Reihenfolge-Liste (hängt an TP5-Deny-by-default + UNTRUSTED-Move).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-09 17:02:49 +02:00
Christoph Emsenhuber
37e17100a4 docs 📄 teilprojekte: offene Notizen geflusht (TP3.1-Interim-Härtung + Migrationsziel) 
- TP3.1: Interim-Härtung ap2 wifi1/wifi2 frame-types=admit-only-vlan-tagged
  (Dual-DHCP-Race 2026-07-06, Provisorium bis VLAN1-Abbau)
- Ist-Stand: Migrationsziel „from scratch" + cudy1-VLAN1-Leak als Aufräum-Liste

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-09 17:02:10 +02:00
Christoph Emsenhuber
82ca6e282c docs 📄 TP7.2: HA↔Sonos static-host binding + VLAN1/GUEST-Discovery 
HA-Sonos waren unavailable: HA hängt auf VLAN1 (10.40.41.105), nicht VLAN20,
und die Sonos-Integration ist SSDP-abhängig (quert VLAN nicht) — frühere
"HA nutzt mDNS/self-healing"-Notiz war falsch.

Fix: static hosts: + advertise_addr in configuration.yaml (discovery-unabhängig,
advertise_addr fixt UPnP-Callbacks trotz Multi-Homing). Zusätzlich VLAN1/GUEST-
Erreichbarkeit: mdns-repeat-ifaces +vlan90,bridge; forward vlan90↔vlan40 (ganzes
MEDIA) + input 5353 vlan90. Flacher-Repeater-Leak bewusst.

- teilprojekte.md: neues TP7.2, TP5/TP7-Regeln nachgezogen
- sonos-inventar.md: HA-Abschnitt korrigiert (SSDP + static hosts)
- tp7-mdns.md: superseding Update-Block (neue Repeater-Ifaces, GUEST-Forward)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-03 08:05:18 +02:00
Christoph Emsenhuber
5fbce5f798 docs 📄 teilprojekte: offene WLAN-Coverage-Arbeit als TP3.3 abgelegt 
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>
 2026-07-03 06:52:26 +02:00
Christoph Emsenhuber
9ac5f5d840 docs 📄 P750W/WLAN-Coverage in CLAUDE.md, teilprojekte, inventory nachgezogen 
- CLAUDE.md: Gotcha CAP-Reachability (dozende Legacy-Clients nur auf ap1) +
  Merkregel DHCP-geht-Ping-nicht=ARP/PowerSave + Coverage/TX/Steering-Stand
- teilprojekte.md: TP3.2 (P750W gelöst, Coverage-Kur offen, Nomenklatur-Realität)
- inventory/bf.md: P750W Web-UI-Pfad + ap1-Pin-Hinweis

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-03 06:47:57 +02:00
Christoph Emsenhuber
cb847b99a8 docs 📄 teilprojekte.md: TP7.1 SSDP-Reflector als Sub vorgemerkt 
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>
 2026-07-02 20:10:31 +02:00
Christoph Emsenhuber
cd804b9766 docs 📄 teilprojekte.md: Edge-Cutover / Sonos-Migration / TP5-teil-live nachgezogen 
Doc-Nachzug gegen den Router-Ist-Stand 2026-07-02:
- Edge-Cutover 2026-07-01 (FB physisch weg, Arris-Bridge, ap1 = Public-Edge) in
  Ist-Stand, TP4-Titel/NAT/FB-Bridge-Block, TP10-Public-Edge-Zeile.
- TP3/TP7/Reihenfolge: Sonos-Migration ✅ (10/10 auf VLAN 40), mDNS-Repeater ✅
  (vlan10/20/40/30), macOS-Desktop-SSDP-Gotcha dokumentiert.
- TP5 auf "teil-live" umgeschrieben: forward MAIN/INFRA↔MEDIA + input 5353 +
  WAN-Seal als bereits gebaut markiert; Deny-by-default bleibt offen.
- TP11: CF-Tunnel #1033 Track A als Sub-Note.
- VLAN 100 in kanonischer Tabelle: FB-Transfer → Arris-Transfer.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-07-02 20:03:56 +02:00
Christoph Emsenhuber
ae6c84dc0b TP3.1 ✅ ap2 VLAN-Trunk-Fix: vlan-filtering=yes (WLAN-Segmentierung) 
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>
 2026-07-01 22:37:03 +02:00
Christoph Emsenhuber
1f8e6b06c2 TP10 ✅ Kern durch: beide WG live auf ap1-Hub, FB-Bridge entblockt 
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>
 2026-06-27 16:44:15 +02:00
Christoph Emsenhuber
dd4c6ad77c TP10 Doku konsolidiert: kanonischer Runbook + kompakter Kontext-Digest 
- 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>
 2026-06-24 14:08:01 +02:00
Christoph Emsenhuber
03f328f043 TP3 📶 ✅ As-built finalisiert: 5 dirtyvader-SSIDs live, Kanal-Plan + Sonos-Diagnose 
- ft=no auf sec-media (802.11r bricht Sonos), ft-over-ds=no
- Kanal-Plan non-DFS/überlappungsfrei: ap1 ch36+ch1, ap2 ch149+ch11
  (Auto-Channel hatte beide APs auf 5500-DFS/2437 = Co-Channel gelegt)
- tp3-capsman.rsc: Channel-Frequenzen, ap1-Interface-Override, Verifikation 2026-06-18
- obsolete capsman-flat-asbuilt/ap1-manager/ap2-cap entfernt (von tp3-capsman.rsc ersetzt)
- teilprojekte.md TP3 → ✅; Sonos-Split-Diagnose in tp7-mdns.md + sonos-inventar.md
  (7 WLAN-Sonos noch auf FB-WLAN/VLAN1 → "selektiv je Netz", kein mDNS-Defekt)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-18 01:11:41 +02:00
Christoph Emsenhuber
b3b23c8b10 TP3 📶 SSID-Nomenklatur fixiert: dirtyvader-<vlan>, INFRA/MGMT hidden 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 21:22:49 +02:00
Christoph Emsenhuber
50870a251f TP10 🅿️ vertagt: gebündelt mit FB-Bridge-Cutover, ap1-Hub geparkt 
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>
 2026-06-17 19:42:55 +02:00
Christoph Emsenhuber
a36c160903 TP10 💡 v6-Variante: WARP→Gelis öffentl. v6-FB als CGNAT-freie Fernwartung 
- 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>
 2026-06-17 18:23:27 +02:00
Christoph Emsenhuber
919f8623c9 TP10 🎯 Root Cause FM-NAT gefunden: FB braucht LAN-IP als WG-Address (Proxy-ARP) 
Echt-Host-Test (Ping realer 10.101.0.10 über WG) -> Antwort aus 10.255.255.2
=> FB masqueradet den Tunnel, bestätigt. Ursache: .conf nutzte Transfernetz-
Adresse (10.255.255.2/32) -> FRITZ!OS = Einzelgerät-Modus = NAT. AVM nutzt
Proxy-ARP statt Transfernetz -> FB-WG-Interface-Address muss die FB-LAN-IP sein
(FM 10.101.0.254/24, DW 192.168.178.1/24), Transfernetz streichen, AllowedIPs
10.40.0.0/16. -> WG-Spoke-Ansatz damit machbar.

- fritzbox-wg-lanlan-klickanleitung.md: Root Cause + One-Field-Fix (LAN-IP als
  Address), LAN-LAN-Wizard, Verify gegen 10.101.0.10.
- teilprojekte.md / tp10-vpn-migration.md: Status "Root Cause gefunden, machbar".

Korrigierte Spoke-Configs in routeros/.secrets/wg-{fm,dw}.conf (gitignored).
FM bleibt auf IPsec (Sicherheitsnetz); ap1-WG-Hub inert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 00:15:32 +02:00
Christoph Emsenhuber
e54e6eb7cb TP10 ⏸ pausiert: FM-Cutover revertiert (IPsec), FB-WG-LAN-LAN-Klickanleitung 
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>
 2026-06-16 21:36:02 +02:00
Christoph Emsenhuber
2c9c1b0e6c TP10 🔐 WG-Hub auf ap1 gebaut (Phase A); Cutover-Runbook FM/DW 
ap1 = WireGuard-Hub (wg-hub, UDP 51821, MTU 1412, keine IF-IP). Port 51821
statt 51820, damit der FB-eigene WG-Server (laufender DW-Tunnel) parallel intakt
bleibt. 2 Peers vorkonfiguriert: FM 10.101.0.0/24 (war IPsec), DW/Geli
192.168.178.0/24 CGNAT (war WG). Routen + Firewall (input/forward) gesetzt;
NAT unverändert (Egress wg-hub != masquerade-Interface).

docs/tp10-vpn-migration.md: As-built + Phase-B-Cutover-Runbook (FB-Import,
L3-Verify, NetBIOS-Lehre, Parallelphase, DDNS-Übergabe für Bridge-Mode).
Spoke-.conf mit Private-Keys liegen gitignored in routeros/.secrets/.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 20:55:47 +02:00
Christoph Emsenhuber
3e59383317 AP4.1 📋 Cutover-Tutorial + Session-Doku — FB-Bridge gegated auf TP10-VPN 
Schärft das Runbook zum vollständigen Solo-Tutorial (Verkabelungs-Diagramm,
WiFi/VLAN-Matrix, Schritt-für-Schritt mit Zurückbau) und schreibt den
Session-Stand für die Fortsetzung fort.

Kernpunkt: FB-Bridge ist nur ein REVERSIBLER TEST. Die BF-FritzBox terminiert
aktuell 2 produktive Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG),
Ziel 2× WG auf ap1 = TP10. Voller Bridge-Mode killt diese Tunnel → permanenter
Umstieg ist auf TP10 gegated (FB bleibt bis dahin Router + VPN + Telefon).

- wan-cutover-runbook.md: TEST-Banner, Verkabelung (ether2=Uplink nie ziehen,
  ether1=WAN), Console = FritzBox-WiFi → 10.40.41.1, install-SSIDs für DHCP-Test,
  wantest-run erklärt, Zurückbau-Schritt.
- docs/teilprojekte.md: Ist-Stand + TP4 (AP4.1 Public-IP bewiesen, Testmechanismus,
  DNS-Upstream jetzt CF-DoH) + TP10 (FB hält 2 Tunnel, gated permanenten Bridge).
- CLAUDE.md: WAN-Testmechanismus, device-mode-Gotchas (scheduler/fetch blockiert,
  [/ping]=nil → :resolve), VPN-Gate, REST-Fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 11:45:41 +02:00
Christoph Emsenhuber
48cdcc0fa2 TP4 ✅ ap1 ist L3-Router — VLAN-Subinterfaces, DHCP, DNS, NAT live 
Bridge vlan-filtering=yes; vlan10/20/30/40/50/90/99 je mit GW .1/24, DHCP-Server
(Pool .100-.200), statischen DNS-Einträgen bf.lan und srcnat masquerade →bridge.
Double-NAT via FB (Interim), FB-Bridge-Mode + Omada-PVID-Fix als nächste Schritte.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 19:24:32 +02:00
Christoph Emsenhuber
f0c08263dd TP2 🔍 Profile-Analyse + TP4 vorgezogen 
Analyse via Omada Controller v2-API (2026-06-15):
- Access-Profile haben PVID=1 statt 10/20 (Constraint: fixe IPs in 10.40.41.x)
- Access-MAIN hat untagNetworkIds=[VLAN1,VLAN10,VLAN20] — bekannter Fehler, Fix nach TP4
- P4 (dock/monitor) → Access-MAIN (Lifeline-Port, nicht anfassen)
- P3/P5/P6 sicher zum Testen, P7/P8 eingefroren
- Network-IDs + v2-API-Pfade dokumentiert (Ctrl-API: Csrf-Token, /switches/{MAC}/ports)
- TP4 vorgezogen: blockiert Profile-Fix + echte VLAN-Segmentierung

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 19:00:40 +02:00
Christoph Emsenhuber
fe477073a3 TP2 ✅ Omada ES208G vollständig konfiguriert — VLANs + Port-Profile live 
- Switch adopted (switchConsistent=true), alle 8 Ports benannt und mit
  Trunk-ALL/Access-MAIN/Access-INFRA Profilen versehen
- omada-mcp Settings-Bug behoben (doppelter Eintrag → .174 statt .176)
- Open-API-Auth dokumentiert: AccessToken=-Header, grant_type als Query-Param
- Ist-Stand und TP2-Abschnitt auf FERTIG aktualisiert; TP4-Hinweis ergänzt

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 18:32:26 +02:00
Christoph Emsenhuber
d99d8cf6da TP2 ✅ omada-mcp live (.176/pve, StreamableHTTP /mcp) — Verbindungstest grün 
Root cause der Crash-Loops gefunden:
- Container bekam Env beim Deploy INLINE (Portainer ignoriert env_file) → alte falsche Var-Namen
- jmtvms/tplink-omada-mcp v0.15 nutzt Omada OPEN API (CLIENT_ID/SECRET), nicht user/pass
- Transport ist StreamableHTTP (MCP_SERVER_USE_HTTP + MCP_HTTP_*), NICHT SSE/MCP_TRANSPORT

Jetzt: /health 200, MCP initialize-Handshake liefert Tools/Capabilities. settings.json → /mcp.
.env-Schema, .env.template, compose-Doku korrigiert.
Offen: Claude Code reload → VLANs anlegen + .12 adoptieren (Tool-Categories ggf. um write erweitern).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 15:07:14 +02:00
Christoph Emsenhuber
bf5d2b2741 TP2 🔄 omada-mcp deployed (.176/pve-LXC) — braucht Open-API-Client-Creds 
- omada-mcp Container auf pve-LXC (.126, endpointId=2, ipvlan .176), Stack Id=200, gestoppt
- Erkenntnis: jmtvms/tplink-omada-mcp nutzt Omada OPEN API (CLIENT_ID/SECRET/OMADAC_ID/SITE_ID),
  NICHT username/password → .env-Schema + compose-Kommentare + .env.template angepasst
- omada-mcp in ~/.claude/settings.json eingetragen (SSE .176:3000)
- Letzter manueller Schritt: Open-API-App im Controller-UI anlegen (Platform Integration),
  Client-Creds + SITE_ID in .env → Container starten → reload → dann VLANs + Adoption

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:49:51 +02:00
Christoph Emsenhuber
8b08d9b5a4 TP2 🔄 Status persistiert: Wizard ✅, omada-mcp staged (Container noch offen) 
- teilprojekte.md: TP2 als IN ARBEIT markiert, offene Schritte präzisiert
  (omada-mcp deployen → Claude Code eintragen → VLANs anlegen → .12 adoptieren)
- INVENTORY.md: omada-controller 🟢 (Wizard done), omada-mcp 🔴 (Container pending)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:26:21 +02:00
Christoph Emsenhuber
a36bdd8f56 TP2 ✅ Omada Controller deployed + omada-mcp staged: DS923/macvlan, pve-mcp eingetragen 
- omada/docker-compose.yml: Controller 6.2.10.17 auf DS923 (macvlan .175, endpointId=14);
  pve-LXC (.126) hat zu wenig Disk → DS923 standard pattern
- mcp/omada/: docker-compose.yml + .env.template für omada-mcp (macvlan .174, MCP_TRANSPORT=sse);
  wartet auf Wizard-Passwort nach https://10.40.41.175:8043
- pve-mcp (samik081) in ~/.claude/settings.json eingetragen (SSE .173:3000)
- CLAUDE.md: Topologie korrigiert (wahre IPs .100/.126/.167/.173-.175, Omada Port 2 = ap2)
- INVENTORY.md: pve-mcp 🟢, omada-mcp 🟡, portainer-mcp zurückgestellt (→ Komodo)
- teilprojekte.md: TP2 ✅, Ist-Stand + offene manuelle Schritte dokumentiert

Noch offen (manuell): Wizard, .12 adopt, Port-Config, .env + Stack deploy, Claude Code eintragen.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:11:05 +02:00
Christoph Emsenhuber
a58d419747 TP1 ✅ ALLNET Core-Switch finalisiert: VLAN 40→MEDIA, VLAN 50 UNTRUSTED, GE8 Trunk verifiziert 
- Neues CLI-Script 04-vlan50-media-untrusted.cli ausgeführt + verifiziert:
  VLAN 40 umbenannt UNTRUSTED→MEDIA, VLAN 50 angelegt (UNTRUSTED),
  GE1/GE2 um VLAN 50 ergänzt; GE8 war bereits Trunk, VLAN 50 auto-includiert.
- Docs: teilprojekte.md TP1 als FERTIG markiert, Ist-Stand aktualisiert,
  VLAN-Gotcha entfernt. core-switch-prep.md Phase A/TP1 Stand ergänzt,
  Switch-IP .239→.11 korrigiert. CLAUDE.md Gotcha aktualisiert, IP korrigiert.
- CLI-REFERENCE.md: VLAN-Namen 40=MEDIA, 50=UNTRUSTED.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 11:33:25 +02:00
Christoph Emsenhuber
e15edc22d7 TP4 DNS: Entscheidung auf RouterOS-nativ + nur statische Records 
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>
 2026-06-15 11:24:05 +02:00
Christoph Emsenhuber
ae4d1e5fcd TP4 DNS: Variante A (RouterOS-DHCP + RFC2136 → BIND9), Technitium verworfen 
- Research-Doc: DHCP→DNS-Registrierung standardnah, PowerDNS-vs-BIND9-Vergleich
- teilprojekte TP4 auf BIND9 + RFC2136 umgestellt + Verweis; HW-Notiz angepasst

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 11:24:05 +02:00
Christoph Emsenhuber
e688b37b60 Teilprojekte + MikroMCP + WLAN-Vorarbeit: Steuerungsdok, Research, MCP-Setup, CAPsMAN-Asbuilt, AP-Trunk-Guides + Port-Map 
- docs/teilprojekte.md: kanonisches Projektsteuerungsdokument (TP1–TP13 + TP-R)
- docs/research/: RouterOS-Capabilities-Sweep (TP-R) + VPN-Vergleich (TP10)
- mcp/: MikroMCP + Portainer-MCP Docker-Compose, routers.yaml, READMEs, .gitignore
- routeros/: ap1-manager.rsc, ap2-cap.rsc, CAPsMAN-Flat-Asbuilt, WLAN-Handover
- switch/cli/03-trunk-ap-ports.cli + switch/ui-guides/01-trunk-ap-ports.md: AP-Trunk-Konfiguration
- docs/allnet-ge8-trunk-klickanleitung.md: GE8 Hybrid→Trunk Schritt-für-Schritt
- inventory/bf-core-ports: gi1/gi2 als TRUNK zu ap1/ap2 eingetragen (gesetzt 2026-06-09)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 08:42:03 +02:00