Christoph Emsenhuber
40ffab1de8
Das gestern eingeschaltete wireless-Logging hat binnen 16 h geliefert, was der 75-Zeilen- Ringpuffer nie konnte: 559 Zeilen, davon 439 (79 %) von Christophs iPhone. Entscheidend ist nicht die Menge, sondern die Trennschaerfe: - `reauthenticating` tritt 93 von 93 Mal bei GENAU EINEM Client auf (dem iPhone) - und 93 von 93 Mal auf GENAU EINER SSID (dirtyvader-main) - was `main` von den anderen fuenf unterscheidet, ist EIN Attribut: ft=yes ft-over-ds=yes Dieselben APs, dieselben Radios, derselbe Zeitraum, dieselben Clients -- die SSIDs mit ft=no zeigen null Ereignisse. Das ist eine saubere Kontrollgruppe. Die WPA3+802.11r- Hypothese, die ich gestern ausdruecklich als "Forenwissen, nicht in der MikroTik-Doku" gefuehrt habe, ist damit durch eigene Messung gestuetzt. Verlauf 2026-08-31 auf cap-wifi6: 07:25 (10x) -> 07:34 (21x), eskalierend, teils mehrere pro Sekunde, endend mit einem Roam auf cap-wifi2 bei -89 dBm -- also der Flucht auf einen 25 dB schlechteren AP. Genau so sieht "Link weg trotz gutem Kontakt, dann Mobilfunk" von der Infrastrukturseite aus. KORREKTUR an meiner eigenen Priorisierung von gestern: 2g-probe-delay war als Hebel 1 gesetzt, weil es der ungefaehrlichste ist. Das war vor diesem Befund und ist falsch -- 2g-probe-delay adressiert Band-Steering, hier liegt ein Authentifizierungsproblem vor. Neue Reihenfolge: (1) ft-over-ds=no, (2) ft=no, (3) 2g-probe-delay, (4) signal-range. Ebenfalls festgehalten: die zwei erfassten "not responding"-Abbruecke liegen bei -80/-76 dBm und sind NICHT dasselbe wie der Schwall -- die Ursprungsmessung vom 08-20 hatte -47. Nicht zusammenwerfen. Noch nichts am Funk geaendert. Der Hebel ist beschrieben, das Messrezept steht im Handoff, und wifi-security ist nicht deploybar (TP22-Regel 1) -- die Aenderung muss am Geraet erfolgen und das Template danach von Hand nachgezogen werden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bf-infra
BF-Netzwerk-Infrastruktur (Caddy, AGH, MikroTik-Konfig, Dokumentation, MCPs).
Aktiver Fork von bf-network-r6 (Claude-Code-Architektur, 2025-2026), ab August 2026
unter OpenCode und anderem LLM weitergepflegt.
Master-Struktur
| Repo | Rolle | Stand |
|---|---|---|
~/dev/bf-infra/ (lokal) |
Aktiver Master, Working-Copy | kein Gitea-Remote (Sicherheitslücke, offen) |
admin/bf-network-r6 (Gitea) |
Archiv, historischer Master | read-only-Header, letzte aktive Commits 2026-08-25 |
admin/bf-golden-config (Gitea) |
Bot-Master (Nautobot 2×/Tag) | intended/ + backups/, nicht manuell |
admin/blaueblueten-n8n (Gitea) |
Master für terpene-Repo | aktiv, lokal synchron |
Was hier lebt
docs/teilprojekte.md— kanonische Steuerung (Ist-Stand, offene TPs, kritischer Pffad)docs/teilprojekte-archiv.md— abgeschlossene TPs (Volltext)docs/handoff-*.md— Session-Übergabencaddy/Caddyfile— Reverse-Proxy BF (siehe TP34 für Migration zu Nautobot/GC)nautobot/— Skripte + Jinja-Template für Golden Configmcp/— MCP-Server-Inventar (SSoT gegen „1000 MCP-Leichen")inventory/— entfernt 2026-08-27 (Pipeline seit 2025-06 stale; Live-Daten via MikroMCP/CF/Portainer)
Status (2026-08-27)
- L3 + WAN-Edge =
crs326-core, alle 4 MikroTik auf RouterOS 7.24 (TP27) - Firewall deny-by-default seit 2026-08-18 (TP5)
- WLAN via CAPsMAN auf dem Core seit 2026-08-17 (TP28)
- Compliance 104/104 grün, 0 Drifts (Golden Config, TP22)
- AdGuard-Paar
agh-bf1/agh-bf2aufgebaut, DHCP noch nicht umgestellt (TP23 Stufe 2 / TP31 Schritt 4) - Caddyfile Reverse-Proxy seit 2026-08-25 (TP31), 16 Sites BF-intern
- terpene.teilzeitladen.xyz: Worker läuft auf Mac mini (10.40.20.167:8890), kein Caddy-Block, kein CF-Tunnel — Backfill via DB-Migration blockiert (Handoff 2026-08-27)
Übergangspfad von bf-network-r6 → bf-infra
- README + Strukturen aktualisiert (dieses File)
- bf-network-r6 im Gitea auf read-only, Header mit Verweis (deine Aktion)
- Inventar-Pipeline gelöscht (XLSX stale, MikroMCP/CF/Portainer liefern Live)
- Caddyfile-Master wandert zu Nautobot/GC (TP34, siehe Handoff 2026-08-27)
- bf-infra bekommt Gitea-Remote (offen, „später")
Werkzeuge (Stand 2026-08-27)
- MikroMCP (RouterOS, 4 Geräte) —
~/.claude.json+opencode.jsonc - pve-mcp (Proxmox, 10.40.20.173) —
opencode.jsonc - home-assistant (HA, 10.40.20.105) —
opencode.jsonc - cloudflare (CF-API, OAuth) —
opencode.jsonc - gitea-mcp (FQDN) —
opencode.jsonc - komodo-mcp (geplant, Migration von Portainer) —
~/dev/bf-infra/mcp/komodo/ - shelly-mcp (Client-lokal Interim, 127.0.0.1:3030) — vor Migration auf zentralen Container