Commit Graph

17 Commits

Author SHA1 Message Date
f482aafc84 TP21.1: Core-Cutover-Recovery — crs326-core als L3-Router live
crs326-core ist jetzt der produktive L3-Router (ersetzt ap1, das
plattgemacht + getrennt wurde). Nach dem Cutover fehlten DHCP, WAN,
WG-Hub und DNS-Upstream -> aus dem letzten ap1-Backup
(ap1-pre-core-cutover-20260806-073616) wiederhergestellt.

- DHCP: 7 Server (dhcp-v10..v99) + 8 Networks + 54 Leases
  (routeros/tp21-core-dhcp-from-ap1.rsc; VLAN1-Legacy + omada-inform weg)
- WAN: dhcp-client vlan100 -> Liwest 90.146.33.177, NAT-Masquerade
  (nur WAN-Variante; disabled bridge/ether1-Regeln bewusst nicht),
  Blackhole-Selbst-Default-Route entfernt
- WG-Hub (TP10): Interface + fm/dw-Peers + Routen; Privkey aus
  gitignored ap1-wg-hub.privkey -> Hub-Pubkey unveraendert, beide
  Spokes handshaken (routeros/tp21-core-wan-wg-restore.rsc, Privkey redacted)
- DNS: allow-remote-requests=yes + plain 1.1.1.1 (core hat certs=0 ->
  DoH-Cloudflare-Gateway ist TODO); entsperrte auch FM (Hub-DNS)
- Identity ap1 -> crs326-core; routers.yaml auf Zielschema
  core .99.1 / branch .99.2 / ap1 .99.11 / ap2 .99.12
- disabled/invalid-Fallen bereinigt: WG-Forward-Regeln mit stale *1D
  Interface-ID -> wg-hub; tote gateway=""-WG-Routen entfernt

Doku: teilprojekte.md TP21.1 + CLAUDE.md HW-Tabelle nachgezogen.
Offene TODOs: DoH-Restore, Nautobot-Write-back, branch-88er-Check,
core ether4, ap1/ap2-Reprovisionierung (WLAN-Rebuild).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-08 17:36:45 +02:00
30301d40e2 TP21: routers.yaml auf finale MGMT-IPs aktualisiert; Sub-TP21.1 CRS326-Branch-Recovery dokumentiert; Nautobot-Image procps-Fix
- mcp/mikromcp/config/routers.yaml: ap1→10.40.99.11, ap2→10.40.99.12,
  crs326-core→10.40.99.1, crs326-branch→10.40.99.2 (tags aktualisiert).
- docs/teilprojekte.md: TP21.1 angelegt — Branch nach Reboot/Lockout recovery.
- docs/nas-vlan20/nautobot-image/Dockerfile: procps installiert (healthcheck).

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-08 11:40:20 +02:00
d281a0f36f TP15: CRS326-Core als L3-Router aktiviert
- crs326-core nimmt Routing/DHCP/DNS/NAT/WAN/WireGuard von ap1 ueber.
- L2-Portplan korrigiert (ap1 #15, Arris WAN #16, branch #8, Sonos #2/3/5/6,
  IoT #14, VLAN10-Access #11, VLAN1-Hybrid #3/7/9/10/12/17-24).
- Backup-RSC gefixt (ether3-24 disabled) und via fixed-RSC eingespielt.
- Gestagede L3-Config enabled in einem Rutsch.
- Falsche statische Default-Route 0.0.0.0/0 -> 10.40.41.1 entfernt,
  WAN-DHCP via 90.146.33.177/24 aktiv.
- SFP-Ports bleiben disabled (Stromersparnis).
- ap1 ist L3-stillgelegt und wird in naechster Session reiner AP.

Backup-Dateien (*.backup) und leases-export.json bleiben lokal.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-07 22:39:29 +02:00
b595c75eef TP15: CRS326-Bring-up (core+branch) + Branch-Tausch gegen sw2 durch
- Beide CRS326 grundkonfiguriert via REST (Governance-Ausnahme #2): core-zuerst
  als L2-Pfad, Zugriff auf Werks-.88.1 über temporäre ap1-.88.2+Masquerade
  (nach Bring-up entfernt). Winbox-MAC scheiterte (sync-timeout).
- branch produktiv, volle SOLL-Portbelegung (ether1 Uplink→sw1#8, 2/8 NAS-20T,
  3 Drucker/4 Dock VLAN10, 5/6 Sonos VLAN40, 7 macmini VLAN20, 24 ap2), mgmt
  .99.13; core grundkonfiguriert nicht produktiv (mgmt .99.11, an sw1#12).
- Branch-Tausch: sw2 physisch raus, Lifelines auf branch; Abnahme grün (NAS/
  macmini VLAN20, Dock VLAN10, Sonos VLAN40). Gotcha: ether3/5-Kabel vertauscht
  (Sonos-VLAN10-Leck/Dual-Homing) → gefixt.
- Nautobot modelliert + GraphQL-verifiziert (nautobot/ingest-crs326-ports.py):
  branch Active + Ports, core Planned + tentativ, sw1 verifizierte 16-Port-
  Belegung (löst UNVERIFIZIERT), sw2 Decommissioning.
- CRS326 in MikroMCP routers.yaml; Creds in ~/.secrets. Doku (teilprojekte/
  CLAUDE/ip-plan) nachgezogen; Core-Swap-Handoff-Prompt neu.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 16:20:26 +02:00
3426366cee chore 🔌 gitea-mcp in .mcp.json registriert + TP17 Shelly-Migrationslog (16 Geräte VLAN1→VLAN30)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:58:37 +02:00
2135772e04 feat 🔌 TP17 GO: 16 Shellys VLAN1→VLAN30 (Anker-Verfahren) + eco-Policy; TP17.2/TP19 angelegt
- migrate.py: anker-sicherer Runner (AP-Anker vor sta-Write, deanchor, auth, table)
- 16 Shellys migriert (Pilot+2 Wellen), 22/26 auf VLAN30, VLAN1 shelly-frei
- eco-Policy RSSI-basiert (AN >= -80, AUS < -80), provisorisch bis TP3.3
- bf.csv: 22 Shelly-Zeilen .41→.30, Section→IOT
- TP17.2 (Geräte-PW, zurückgestellt/Kosmetik) + TP19 (cudy-Teardown + VLAN1-Retirement) angelegt
- Verlorene Küchen-Shelly via HA identifiziert (Plug S Gen3, e4:b0:63:e4:1a:b8, bogus-IP 10.95.10.206 auf elektrosmog.c) → Remote-Recovery-Plan in TP19

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 17:27:56 +02:00
248b1b5e74 feat 🔌 TP17: statische Shelly-IP + in-pool-Reservierung + voller HA-MAC-Scan
- 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>
2026-07-11 07:45:08 +02:00
794082fd74 feat 🔌 shelly-mcp set_auth-Tool + Digest-Auth-Fallback (TP17 Geräte-PW)
- set_auth: setzt einheitliches Admin-PW (SHELLY_DEVICE_PW) via Shelly.SetAuth,
  realm=Geräte-ID, ha1=sha256("admin:realm:pw") pro Gerät; guarded (confirm/dry-run).
- _rpc: HTTP-Digest-Fallback (user admin) bei 401 → Geräte bleiben nach set_auth managebar.
- .env.example/README: SHELLY_DEVICE_PW dokumentiert (getrennt vom WLAN-PSK); Rollout mit PW-Schritt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 07:17:16 +02:00
e76289c8e9 feat 🔌 shelly-mcp + TP17 Shelly-Migration VLAN1→VLAN30; TP14.3 dormante Stacks bereitgestellt
TP17 (neu): shelly-mcp (eigenbau, FastMCP StreamableHTTP :3030 + Status/Health-Seite,
in .claude/launch.json) mit Tools discover/get/set_sta[guarded]/verify/reservation_plan.
Recon: 16 Shellys live, alle Gen3/4 (RPC WiFi.SetConfig, auth=off). Inventar-Fix:
s6/kueche_kuehlschrank MAC 0c:72… → real d0:cf:13:d8:18:fc.

TP14.3: 7 dormante Stacks als .new.yml bereitgestellt (nur lokal, gitignored) — SSoT
in docs/teilprojekte.md nachgezogen.

mcp/INVENTORY.md: shelly-mcp-Zeile + Richtungsentscheid „MCPs zentral, nicht Client;
MikroMCP+shelly-mcp sind pragmatische Interims, später zusammenziehen".

.gitignore: __pycache__/*.pyc.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 01:15:32 +02:00
381365b8ed CF/#1033 📄 CF-Tunnel-Mapping (SSoT) + cloudflare-MCP-Scaffold
- 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>
2026-07-01 17:49:46 +02:00
e2c2700252 Sonos 🔍 Inventar (10 Geräte, alle S2) + zero-dep :1400-Helper
- 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>
2026-06-17 20:31:11 +02:00
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
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
c5d4ee8bfa TP2 📋 Komodo-Migration geplant: Core/Periphery/MCP Compose + MIGRATION.md
Portainer CE 2.40 hat keinen passenden portainer-mcp (erst ab 2.41) → Entscheidung:
Ablösung durch Komodo + Samik081/mcp-komodo (selber Autor wie pve-mcp).

- mcp/komodo/MIGRATION.md       — 5-Phasen-Plan (Export → Core → Periphery → Stacks → MCP)
- mcp/komodo/core-compose.yml   — Komodo Core + MongoDB auf pve-LXC (.126:9120)
- mcp/komodo/periphery.compose.yml — Agent-Template für DS923/.10, odroid/.7, macmini/.167, nas-fm
- mcp/komodo/komodo-mcp-compose.yml — MCP-Adapter, macvlan .176, SSE :3000
- mcp/komodo/.env.example       — Secret-Vorlage
- mcp/INVENTORY.md              — portainer-mcp auf ⏳ retiring, komodo-mcp als 🟡 geplant eingetragen

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 14:42:52 +02:00
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
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
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