ac4bce8cc254658e022feff0d7c6777c02fc2448
Die Auswertung liest jetzt beide Geraete und stellt sie je Raum untereinander: REFERENZ (iPhone, frei) was du an dieser Stelle wirklich hast SONDE (S22, Gegen-AP) was die Rueckfallebene noch leisten koennte Damit faellt der Terrassen-Vergleich beim naechsten Lauf von selbst raus, und die Lesart wird eindeutig: gute Referenz + schlechte Sonde = alles haengt an EINEM AP; beide schlecht = echtes Loch ohne Rueckfallebene (der Kuechenfall). Rueckwaertskompatibel: Laeufe ohne walk-ping-iphone.csv/beide-telefone.csv laufen einspaltig weiter und liefern fuer den Lauf vom 22.8. Ziffer fuer Ziffer dieselben Zahlen wie vorher. Das Geraet heisst dort "Geraet" -- welches es war, steht in den Dateien nicht, also wird es auch nicht behauptet. Drei Fehler, die der Abnahmetest zutage foerderte und die alle den naechsten Rundgang gekostet haetten: 1. Die Gegen-AP-Automatik war nach dem Start AUS. Wer den Klick vergisst, geht die ganze Runde mit beiden Telefonen auf DEMSELBEN AP -- im Test genau so passiert. tp25-runde.sh schaltet sie jetzt scharf; /auto nimmt dafuer ?an=1 (ein Toggle waere falsch: bei schon laufender Konsole haette der Start sie ausgeschaltet). 2. "Funk da, aber keine einzige Ping-Antwort" erschien als "—", also wie eine Datenluecke. Beim Test lag das iPhone gesperrt auf dem Tisch: angemeldet mit -47 dBm und trotzdem stumm. Wer das als Luecke liest, sucht danach ein Funkloch, das es nicht gibt. Jetzt: "keine Antwort" + "⚠️ Display gesperrt?". 3. Der Aufraeumer meldete "AP-Pin geloest", und danach standen die Regeln trotzdem am Core. Wettlauf: er loeste den Pin, waehrend die Konsole noch lief, und deren Automatik setzte ihn binnen zwei Sekunden wieder. Das Telefon waere nach JEDER Runde gepinnt geblieben. Jetzt erst Konsole toeten, dann Pin loesen. Zuletzt: tp25-pin-s22.sh laeuft auf sshpass -e. Damit steht das Router-Passwort in keiner Kommandozeile mehr -- `grep -rn "sshpass -p" docs/ nautobot/` findet nur noch die Erwaehnung in teilprojekte.md. Die Rotation kann jetzt kommen. Abnahme (mehrere echte Laeufe): Automatik meldet EIN, beide Telefone stehen auf verschiedenen APs, beide werden gepingt, ein Klick auf Stopp beendet alles, Pin danach "off", kein Prozess uebrig. 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%