Christoph Emsenhuber
2f183190ed
Christophs strukturelle Frage hat TP17.1 gekippt: "zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber wenig wenn man das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann ohne reset." Der Pilot hat den Weg technisch vollstaendig bewiesen -- und gezeigt, dass das Ziel so nicht erreichbar ist. Das Geraet bleibt WLAN-Client; der gemessene Funkgewinn ist klein (12 von 26 IoT-Clients, je 150-200 KB rx / 0,6-3 MB tx in sechs Stunden); und WLAN abzuschalten waere unumkehrbar, weil die Zigbee-Firmware keinen AP hat, Shelly kein Zigbee-OTA macht und InstallAlt eine IP braucht. Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar. Das Runbook bleibt als Wissensspeicher. Rueckbau: ZHA-Knoten entfernt -- Leave VOR dem Flash, damit kein Geisterrouter im 52-Geraete-Mesh bleibt. s9 zurueck auf PowerStrip, Config aus dem Backup. Alle vier roten EZSP-Zaehler blieben 0, Retry-Quote fiel im Delta auf 8,9 %. Neue Merkregel: der Rueckflash zog einen OFFENEN AP hoch (ap.enable=true, is_open=true). Abgeschaltet und mit dem IoT-PSK abgesichert. Nach jedem Shelly-Firmwarewechsel den AP pruefen. eco_mode flottenweit aus (User: "der rotz macht nur probleme"): 13 Geraete umgestellt, null Fehler, 9 standen schon so. Jetzt eco=false auf allen 22 erreichbaren Shellys ausser s24, das es nicht unterstuetzt. Dafuer migrate.py um ein eco-Kommando ergaenzt -- mit Retry je Geraet, weil ein Timeout an einem schwachen Link den Sweep sonst abreisst. Die Gegenmessung widerlegt meine eigene Warnung: eco aus hebt die Sendeleistung NICHT messbar an. 13 geaenderte Geraete im Mittel -0,9 dB, Kontrollgruppe von 13 unveraenderten +0,0 dB bei gleicher Streuung. Die TP17-Aussage, eco senke Takt UND Sendeleistung, stimmt nur zur Haelfte. Vorbedingung der Passwort-Rotation geprueft: alle vier Skripte laufen laengst auf sshpass -e, die gegenteilige Notiz war veraltet. Uebrig war CLAUDE.md, das sshpass -p weiterhin aktiv als Reboot-Weg empfahl -- genau das Muster, das den Leak verursacht hat. Auf sshpass -e korrigiert. TP17.2 aus "zurueckgestellt" aktiviert und an die PSK-Rotation gekoppelt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MCP-Control-Plane — BF
Zentrale, versionierte MCP-Server für BF. Übersicht aller MCPs: INVENTORY.md. Ziel: ein nachvollziehbarer Satz MCPs (gegen "1000 MCP-Leichen"), zentral als Container, FQDN-adressiert.
MikroMCP (MikroTik ap1/ap2)
REST-primär + guarded SSH; RouterOS-7-nativ; Safety: dry-run, plan_changes/apply_plan/rollback_change,
Confirmation-Tokens, RBAC, Audit-Log. Image: ghcr.io/alikarami/mikromcp:latest.
Zwei Betriebsarten
- A — lokal stdio (schnell, kein Netz-Exposure): läuft dort wo Claude läuft, RBAC = built-in superadmin, keine Tokens/Secret nötig. Gut für sofortige WLAN-Arbeit. Trotzdem in INVENTORY eintragen.
- B — Docker HTTP auf Mac mini (zentral, Ziel):
docker-compose.yml. Erfordert Confirmation-Secret + Bearer-Token-Identität. Endpoint später hinter NPM (FQDN+Auth).
RouterOS-User (beide APs) — NICHT admin verwenden
/user group add name=mcp policy=read,write,api,rest-api,test,ssh,sniff,!ftp,!policy,!password
/user add name=mcp-api group=mcp password=<stark>
(ftp nur falls upload_file gebraucht wird; sniff nur für torch. SSH-Dienst muss laufen für
ping/traceroute/torch/run_command — REST blockt diese Befehle generell.)
B deployen (Mac mini 10.40.41.167)
openssl rand -hex 32 # -> MIKROMCP_CONFIRMATION_SECRET
# identities.yaml aus identities.example.yaml bauen (Token: openssl rand -hex 32, dann bcrypt-Hash):
node -e "const b=require('bcryptjs');b.hash(process.argv[1],12).then(console.log)" <raw-token>
scp -r mcp/mikromcp 10.40.41.167:/opt/docker/mikromcp
ssh 10.40.41.167 'cd /opt/docker/mikromcp && cp .env.example .env' # .env + config/identities.yaml füllen
ssh 10.40.41.167 'cd /opt/docker/mikromcp && docker compose up -d && docker compose logs --tail=50'
Smoke-Test: curl -s http://10.40.41.167:3000/health bzw. MCP-Initialize mit Bearer-Token.
In Claude Code einhängen
- A (stdio):
claude mcp add mikromcp -- npx -y mikromcp+ ENV (MIKROMCP_CONFIG_PATH,ROUTER_AP1_USER/PASS, …). - B (http):
claude mcp add --transport http mikromcp http://10.40.41.167:3000(HeaderAuthorization: Bearer <raw-token>). Nach FQDN: URL aufhttps://<fqdn>umstellen.
omada-mcp (TP-Link ES208G)
Wartet auf: Omada-Controller (≥6.1.x, ../../omada/docker-compose.yml, Ziel pve-LXC 10.40.41.126) up +
ES208G adoptiert. Env: OMADA_BASE_URL, OMADA_CLIENT_ID/SECRET, OMADA_OMADAC_ID, OMADA_SITE_ID,
OMADA_STRICT_SSL=false (self-signed). Tools: Switch-Ports/VLAN/Firewall CRUD. Details: INVENTORY.md.
Sicherheit (wichtig)
Ein MikroMCP/omada-mcp-HTTP-Endpoint kann Infrastruktur administrieren. Daher: nur auf LAN-IP binden, dedizierte Nicht-admin-User, Confirmation-Secret gesetzt, Audit-Log an, später NPM+Auth+TLS+FQDN davor.