c9a8256e9fbc413adbbb6b4f0683b45df6097502
Auftrag war, den nicht abschaltbaren DTU-AP von ch1 wegzubekommen, indem man den Client per access-list an ap2 bindet. Transaktion TP17.1-dtu-pin-ap2 eroeffnet, fuenf reject-Regeln auf ap1s 2,4-GHz-Interfaces deployt. Der DTU flog um 14:38:48 von ap1 und kam bei ap2 nie an. Nach 2,5 Minuten zurueckgerollt, access-list ist wieder leer. Ursache ist Christophs Verdacht und protokollseitig belegbar: SetConfig.proto kennt channel_select (Feld 9). Der eigene AP des Geraets sendet auf ch1, und ein ESP hat ein Radio -- AP und STA teilen zwingend den Kanal. ap2 laeuft auf ch11, dort kann das Geraet gar nicht assoziieren. Die Sperre hat es also nicht umgeleitet, sondern ausgesperrt. Christophs Wiederverbindungsversuch ueber S-Miles scheiterte mit genau der Meldung, die er von Frequenz-Fehlanpassungen kennt. Damit ist meine Empfehlung "AP-Kanal verschieben, indem man den Client bindet" fuer dieses Geraet widerlegt und im Text durchgestrichen. Sie gilt weiter fuer frei scannende Geraete wie die Shellys. Zwei Merkregeln festgehalten: - Ein reject auf AP A ist keine Umleitung auf AP B, sondern ein Rausschmiss. Ob das Geraet woanders unterkommt, ist seine Entscheidung. Bei fixem Kanal: nirgends. - Vor einem Pin pruefen, ob der Client den Kanal des Ziel-APs ueberhaupt benutzen kann. Der Beleg lag vor: DTU-AP auf 2412, ap2 auf 2462. Signalstaerke ist kein Nachweis fuer Assoziationsfaehigkeit -- meine Abnahme war zu lasch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%