bf-infra/docs/handoff-tp25-session-20260821.md

Übergabe: TP25-Session — vom Verdacht zur Raumkarte

Stand bei Übergabe: 2026-08-21, alles live verifiziert und committet. Diese Datei ist der Einstieg. Der Arbeitsplan steht in tp25-wlan-roaming-messung-20260820.md; hier steht, was du wissen musst, bevor du ihn aufschlägst.

---

1. Dein Auftrag in zwei Sätzen

TP25 ist der kritische Pfad. TP6 ist am 2026-08-20/21 gemessen und entschieden — formal Fall B, aber im Videocall nicht wahrnehmbar; die Zahlen stehen in tp6-praemisse-messrunbook.md §5 und TP6 ist bewusst nachrangig. Was die Calls tatsächlich zerreißt, ist der Funk, und der ist jetzt raumgenau vermessen.

---

2. 🔴 Zuerst: es ist eine Transaktion offen

TEST-ether3-trunk-ap1-sideboard    OFFEN    crs326-core    Scope bridge-vlan    Frist 2026-09-04

Die Compliance ist absichtlich nicht 92/92. ether3 wurde zum Trunk gemacht, damit ap1 an seinem neuen Platz (Sideboard) überhaupt läuft — die Änderung steht am Gerät, aber nicht in der SoT. Das ist kein Versehen, sondern der Zustand „uncommitted".

python3 nautobot/gc-transaktion.py status

Geschlossen wird sie so:

• Bleibt ap1 am Sideboard → Template nachziehen (ether3 in die sieben tagged-Listen, und aus der untagged-Liste von VLAN 40 raus), dann --refresh-compliance, dann gc-transaktion.py commit --change-id TEST-ether3-trunk-ap1-sideboard. Der Commit verweigert sich, solange der Scope noch driftet — das ist die eingebaute Sicherung gegen einen Commit, der nur behauptet, die SoT sei nachgezogen.
• Geht ap1 zurück auf ether15 → gc-transaktion.py rollback --change-id … erzeugt aus dem Snapshot einen Rückbau-Vorschlag; prüfen, per gc-manual-plan.py deployen, dann rollback --erledigt.

Hintergrund zum Mechanismus: docs/transaktionen/README.md.

---

3. Verifizierter Ist-Stand (nichts davon neu erheben)

ap1	am Sideboard, Uplink crs326-core ether3 (trägt jetzt VLAN 10/20/30/40/50/90/99), erreichbar in 447 µs, 12 Clients
ap2	unverändert am Boden im Arbeitszimmer, 16 Clients
SSIDs auf Sendung	fünf, nicht sechs: main, iot, media, untrusted, guest. cfg-infra existiert als Objekt, ist aber in keiner Provisioning-Regel → nie ein VAP. Kein Drift.
pro Radio	5 GHz: 4 SSIDs · 2,4 GHz: 5 SSIDs (Beacon-Airtime, relevant in dichter Nachbarschaft)
802.11k/v/FT	aktiv (st-main, rrm=yes, wnm=yes, ft-over-ds=yes) — ref_ft_is_not_roaming ist historisch
Kanäle	ap1 5180 (ch36) / 2412 · ap2 5220 (ch44) / 2462, 5 GHz auf 20/40 MHz
Übergabekosten	bei gutem Signal 0–2,6 s, meist unter 0,4 s — gemessen, nicht geschätzt
TP6	Upload-Last +28…+47 ms; Call lief durch ohne einen einzigen Problem-Klick
Linerate	9,6 Mbit up / 54,6 Mbit down (stand vorher nirgends im Repo)

---

4. Messstand TP25 — zwei Raumkarten

Raumkarte 1, ap1 am alten Platz (2026-08-20 abends) · Raumkarte 2, ap1 am Sideboard (2026-08-21). Signal = Durchschnitt, wie der Manager den Client sieht.

Raum	Karte 1	Karte 2
Technik UG	−43 (ap1/5)	—
Diele UG	−44 (ap1/5)	−69	schlechter
Kinderzimmer	−53 (ap1/5)	−75	schlechter
Schlafzimmer	−61 (ap1/5)	−83 (ap2/2,4)	deutlich schlechter
Bad	—	−83, 31 % Verlust	schlecht
Küche	—	−61 (ap1/5)	gut
Wohnzimmer	—	−59 (ap1/5)	gut
Treppe	−51	−62	ok
Arbeitszimmer	−49	−50	gut
Technik OG	−56	−44	besser
Diele OG	—	−50, 0 % über 5,5 min	sehr gut
Terrasse	−72, 43 % Verlust, 20,4 s Lücke	−55 am Telefon-Platz	s. u.

Zur Terrasse, korrigiert: der Platz, an dem das Telefon normalerweise steht, ist mit −46 bis −66 dBm gut. Schlecht ist der Teil dahinter (Karte 1, −72 dBm). Die 51 % Verlust in Karte 2 sind kein Funkloch, sondern Ruhezustand — siehe §6.

Kurzfassung: das Sideboard verbessert das OG und opfert die Schlafräume.

---

5. Die Frage, die als Nächstes drankommt

Christophs Maßangaben (2026-08-21) drehen den Befund um:

Schlafzimmer und Kinderzimmer liegen 2 bzw. 4 m Luftlinie von ap1. ap2 ist 4–6 m entfernt, mit zwei zusätzlichen Mauern dazwischen. Kinderzimmer liegt < 1 m an der Trennmauer zum Schlafzimmer.

Gemessen wurde aber: beide Räume hängen an ap2 auf 2,4 GHz bei ⌀ −83 dBm.

🔴 Ein Client, der bei 2 m Luftlinie zum besseren AP am schlechteren klebt, hat kein Abdeckungsproblem, sondern ein Steering-Problem. Damit ist das die erste Stelle in diesem Haus, an der Fund E (signal-range-Boden) wirklich hilft — hier gibt es eine bessere Alternative; auf der Terrasse gab es keine, dort hätte derselbe Boden nur rausgeworfen.

Test, bevor irgendetwas gesetzt wird:

bash docs/tp25-walk-messung.sh

Derselbe Gang, aber in jedem Schlafraum stehen bleiben und alle 10–20 s die Konsole antippen (hält das Telefon wach — sonst sind die Verlustzahlen wertlos, s. §6). Protokollieren, ob und wann der Client von ap2 auf ap1 wechselt. Auswertung: python3 docs/tp25-gehweg-auswertung.py --dir <run-dir>.

---

6. Fallen, die in dieser Session je einen Fehlbefund gekostet haben

Falle	Symptom	Merkregel
Ruhezustand ≠ Funkloch	58 s Ping-Lücke bei −53 dBm und 275 Mbps PHY	iOS beantwortet ICMP mit gesperrtem Display nicht. Bleibt Signal und Rate hoch, war das Gerät erreichbar. Die Auswertung markiert das jetzt.
Teilzustand nach Failed	6 von 7 VLANs gesetzt	ether3 war in VLAN 40 untagged — ein Port kann nicht zugleich tagged und untagged sein. Nach jedem Fehlschlag am Gerät nachzählen.
CF-403 ohne User-Agent	saubere Ping-Reihe über tote Flows	speed.cloudflare.com/__down antwortet curl mit 403 + 1 Byte. Aufgefallen nur am Core-Sampler (164 kbit statt 50 Mbit).
Treiber-Heartbeat	5,5 min Call ohne Messung	Start-Klick ohne laufenden Treiber schreibt nur einen Marker. Die Konsole warnt jetzt sichtbar.
RouterOS + SSH-Mehrzeiler	expected closing brace	Die Console parst zeilenweise; als Einzeiler braucht jeder do={}-Block ein abschließendes ;.
tr puffert blockweise	CSV scheinbar leer	In Pipes 4-KB-Puffer. \r im Shell-Loop entfernen, nicht per tr.
Marker URL-kodiert	RAUM%3DDIELE%20OG	Erst unquote, dann nicht hochschreiben.
NAUTOBOT_TOKEN	Abbruch nach dem Dry-Run	gc-manual-plan.py braucht die Variable im Environment (steht in docs/nas-vlan20/stacks/210-nautobot.yml, gitignored).

---

7. Werkzeug, das diese Session hinterlässt

Datei	Zweck
tp6-monitor-core.sh	Core-Sampler: CPU, WAN-Rate, Client-Funkwerte im Sekundentakt, mit Reconnect
tp25-walk-messung.sh	Gehweg-Messung: Ping vom Core aufs Telefon + Sampler
tp6-marker/server.py	Klick-Konsole fürs Telefon: Phasen, Anweisungen, Not-Aus, Raum-Buttons
tp25-gehweg-auswertung.py	Tabelle je Raum: Signal, Verlust, längste Lücke, AP
tp6-auswertung.py	Phasenauswertung der Sampler-CSV
../nautobot/gc-transaktion.py	begin/status/commit/rollback für Teständerungen

Rohdaten aller Läufe: docs/messdaten/.

---

8. Spielregeln (unverändert, plus eine neue)

1. Config-Änderungen ausschließlich über Nautobot Golden Config. Kein Direkt-Write per MikroMCP.
2. NEU: Teständerungen bekommen eine Transaktion. gc-transaktion.py begin vor dem Deploy — mit Scope und Frist. Ein Drift ohne Akte ist ab jetzt ein Fehler, kein Versuch.
3. Abnahme misst Wirkung, nicht Anzeige. --assert liest am Gerät; bei Funkänderungen monitor, nie das Profil.
4. Bei Statuswechseln den Header mitziehen. Der wiederkehrende Fehler dieses Repos.
5. Eine Session zur Zeit an diesem Repo. git pull vor dem ersten Edit.

9. Nicht dein Auftrag

TP6 neu aufrollen (gemessen und entschieden), Fasttrack-Reihenfolge (entschieden), CF-Writes. Und: kein neuer AP, solange die User-Randbedingung gilt — erst muss aus den vorhandenen alles herausgeholt sein, und mit dem Steering-Test aus §5 ist genau das noch offen.