Christoph Emsenhuber
175486221b
Auslöser war eine unabhaengige Meldung: seit Tagen/Wochen verliert das iPhone den WiFi-Link bei gutem Signal und landet auf Mobilfunk. Auf Mobilfunk zu fallen ist KEIN Roaming-Problem -- bei schlechtem Roaming bliebe das Telefon im WLAN und waere nur langsam. Es heisst, die Assoziation ist gestorben und die Neuanmeldung gescheitert. Der Manager-Log zeigt dasselbe iPhone (F2:62:4C:E1:AF:09) mit 16 Bandwechseln in 20 Minuten zwischen ap3s 5-GHz- und 2,4-GHz-Radio, zweimal im Abstand von einer Sekunde, bei -53..-81 dBm -- kurz darauf dasselbe an ap2. Also nicht ap3-spezifisch. Das stand schon im Repo: TP25 Fund E beschreibt es seit dem 2026-08-20, mit derselben MAC und der Zeile "disconnected, not responding, signal strength -47" -- Abbruch bei ausgezeichnetem Signal. Fund E war zurueckgestellt mit der Auflage "erst wieder aufgreifen, wenn ein Sticky-Fall erneut gemessen ist". Die ist eingetreten. Das ist heute der zweite Fall (nach dem TP25-Kanalplan fuer ap3), in dem eine fertige Analyse im TP-Body stand und ich sie erst nach einer Extrarunde gefunden habe. Der eigentliche Mangel war aber die Beweislage: `wireless` lief NUR nach action=memory, nur `firewall` ging in den Kollektor. Der Ringpuffer fasste 75 Zeilen und war von einer Stunde ap3-Arbeit fast ueberschrieben -- rueckwirkend war nichts diagnostizierbar. Jetzt: zwei Regeln am Core (topics=wireless und topics=caps) in denselben Kollektor wie TP5 (10.40.20.18:514). Gegenprobe auf beiden Seiten -- 32 Zeilen liegen bereits im Tagesfile, inkl. `associated` (debug) und `connected` (info). Und unter Drift-Kontrolle, denn /system logging stand unter KEINER der 26 Rules und gar nicht im Template: neue ComplianceFeature/Rule `system-logging` (Muster: TP6 /queue, TP26 /ip firewall filter), Template-Block [6a2] nur im Core-Zweig -- RouterOS exportiert Defaults nicht, auf ap1/ap2/ap3/branch sind Soll und Ist beide leer. Compliance 130/130 -> 135/135, 0 Drifts. Die Zahl MUSS sich bewegen: eine gleichbleibende Zahl nach dem Hinzufuegen einer Regel waere ein Befund, kein Erfolg. Zwei RouterOS-Fallen, beide als Gotcha in CLAUDE.md: - Der Topic heisst `wireless`, NICHT `wifi` -- auch auf dem neuen wifi-qcom-Stack. Ein geratenes topics=wifi waere wirkungslos geblieben. - RouterOS UND-verknuepft Topics innerhalb EINER Regel (`info,!firewall` = info UND NICHT firewall). `topics=wireless,caps` haette NICHTS gematcht -> zwei Regeln. Recherche-Ergebnis gegen die offizielle MikroTik-Doku, das meine eigene erste Hypothese widerlegt: transition-threshold steht per Default auf -80 dBm (-time 10s, -request-period 30s, -count 3), und unsere Steering-Objekte setzen davon nichts. Bei -53..-74 dBm wird das iPhone gar nicht Transition-Kandidat -- unsolicited BTM scheidet als Treiber weitgehend aus. Die vielzitierte WPA3/802.11r-Inkompatibilitaet steht NICHT in der Doku (dort nur: FT geht nicht ueber OWE); sie bleibt Hypothese. BEWUSST NICHT geaendert: kein einziger Funk-Parameter. Drei Hebel sind dokumentiert und priorisiert -- (1) 2g-probe-delay=yes, kann keinen Client stranden lassen, (2) ft-over-ds=no, nimmt die Aenderung vom 2026-08-17 zurueck, (3) signal-range-Boden, der invasivste und einzige, der Clients aussperren kann. Einzeln, je als Transaktion, erst mit Daten. 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