Christoph Emsenhuber a94aa92826 Die Terrasse ist repariert -- und das Netz ist besser als seine Redundanz
Erster Lauf mit beiden Ping-Strecken (23:30-23:41, per Stopp-Knopf beendet).

TERRASSE, die Frage des Aufbaus:
  2026-08-21, ap2 tief:      43 % Verlust, laengste Luecke 20,4 s, -72 dBm
  2026-08-22, ap2 auf 2,5 m:  9 % Verlust, laengste Luecke  1,0 s, -69,0 dBm
Gleiches Geraet, gleiche Rolle. 1,0 s liegt unter der Hoerbarkeitsschwelle im
Videocall. Der Dead Spot, der TP25 seit dem 08-20 getragen hat, ist weg.

STRUKTURBEFUND: die Referenz hat in 17 von 21 Raumabschnitten 0 % Verlust --
die Alltagsabdeckung ist ueberall in Ordnung. Der Gegen-AP traegt dagegen fast
nirgends: Schlafzimmer -84,6/38 %, Bad -82,3/24 %, Kueche -82,0/23 %, Terrasse
-78,7/19 %. Faellt ein AP aus, ist die halbe Wohnung "verbunden, aber tot".
Ein dritter AP kaufte damit REDUNDANZ, keine Abdeckung -- nach Christophs
eigener Randbedingung derzeit nicht begruendet.

KORREKTUR zum 22:43-Lauf: "die Kueche ist ein Loch fuer beide APs" gilt nur
fuer die aeusserste Ecke. Hier hat die Referenz in der Kueche 1 % Verlust bei
-71 dBm. Der Unterschied ist der Weg -- der Vorlauf ging ausdruecklich allen
Waenden entlang in die totesten Winkel. Beide Aussagen gelten, sie messen
verschiedene Orte.

Fund E weiter abgestuft: der Sticky-Client vom 08-20 reproduzierte sich nicht
(Treppe: sauberer Wechsel ap2/5G -> ap1/5G, 0 % ueber 57 s). Nicht umsetzen,
bevor ein Sticky-Fall erneut gemessen ist. Ein Lauf widerlegt Fund B nicht,
er zeigt nur, dass es nicht der Normalfall ist.

WERKZEUG: die Auswertung wies die groesste Sonden-Luecke auf der Treppe als
"⚠️ eher Ruhezustand" aus (4,6 s). Das war unser eigener Eingriff -- um
23:35:10 wechselte der Pin, das S22 war 23:35:12-16 abgemeldet. Ein Artefakt
als "Geraet war erreichbar, wollte nur nicht" zu beschriften ist doppelt
falsch. Pin-Wechsel werden jetzt erkannt und als solche benannt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:45:27 +02:00
2026-06-15 19:00:40 +02:00

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 & Phasen
  • docs/firmware-flash-runbook.md — FW-Flash Historie
  • switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
  • switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
  • inventory/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.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%