bf-infra/docs/handoff-20260914-tp25-ap2-insitu-terrassse.md

Handoff 2026-09-14 — TP25: ap2-In-situ-Messung (Terrasse), Hebel-A-Machbarkeitsprüfung

Anlass: Christoph beobachtete 19:18 auf der Terrasse springende WLAN-Balken (1→2→3 binnen Sekunden) und zwei Anruf-Aussetzer; danach Umstellung des Telefons auf 5G-Zellular. Verdacht: Das Telefon probe die APs ab und falle dabei hinaus.

Beteiligte: iPhone F2:62:4C:E1:AF:09 (das bekannte Fund-E-Gerät), Manager crs326-core. Alle Reads am Manager; kein einziger Geräte-Write in dieser Session.

cap-wifi-Karte (verifiziert live 19:22, vor jeder Auswertung gelesen)

cap-wifi1 = ap2 5G (5300/ax/Ce/DI, tx-power 18) · cap-wifi6 = ap2 2,4G (2462, tx-power 15) · cap-wifi2 = ap3 5G (5180) · cap-wifi4 = ap3 2,4G · cap-wifi3/cap-wifi5 = ap1 (5G 5280/2,4G). ⚠️ Das CLAUDE.md sagt „ap1 FUNKSTILL seit 08-30" — überholt: seit dem 09-04-Kanalplan-Commit hat ap1 wieder eine Provisioning-Zeile und dient live (heute 16:51:53 sogar ein Radar-Event auf 5280 mit sauberem Kanalwechsel auf 5260/5280-Liste). Doku-Drift, hier vermerkt.

Befund 1 — das Flapping ist echt und überwiegend band-intern an ap2

Kollektor-Log 18:53–19:18: ~30 Roams, fast alle cap-wifi1 ↔ cap-wifi6 = ap2 5G ↔ ap2 2,4G (derselbe AP), Feldstärke −68…−81 dBm. Drei echte Abwürfe disconnected, not responding (19:01:29, 19:12:10, 19:47:51 — der letzte tötete den Anruf). Ein Ausflug zu ap1-5G (19:35:45, −64) und ap3 (−78…−82).

Befund 2 — In-situ vor ap2: Hardware-Verdacht WIDERLEGT

Christoph stellte sich 1–2 m vor ap2. Registration-Table live (3 Stichproben + Log):

Position	Interface	Signal	Verhalten
1–2 m vor ap2	cap-wifi1 (5G)	−49…−51	>2 min stabil, 0 Roams
Rückweg (Weg)	cap-wifi1 → cap-wifi6	−76…−78	2 Roams binnen 26 s
Terrassenplatz	cap-wifi6 (2,4G)	−65…−73	36 s im 1-s-Takt, 0 Roams, ±4 dB

⇒ Der offene TP25-Unterpunkt „ap2 unterperformt (2 m/−80, 23:02-Befund)" ist in situ widerlegt: ap2 sendet auf 2 m mit −49…−51 dBm und bleibt dort stabil. Der 23:02-Befund reproduziert sich nicht — plausibel, weil seitdem der 09-04-Kanalplan (5220→5300/5320, Band-B-Liste) committed ist; alternativ war die damalige Position/Attribution anders. ap2 RF/Antenne/HW: sauber. Kein Hardware-Tausch begründet.

Befund 3 — Ursache-Modell Terrasse: 5-GHz-Zellkante + client-getriebene Band-Aggressivität

• Terrassenplatz: 5 GHz −76…−81 (Zellkante), 2,4 GHz −65…−73 — die ~7 dB sind normale Bandspreizung plus Wand. Link-Budget, kein Defekt.
• Das iPhone bleibt, sobald ein Band klar gewinnt (am Platz: 2,4 GHz, minutenlang ruhig). Das Thrash passiert ausschließlich in der Überlappungszone −70…−77, wo beide Bänder gleichauf liegen und 5 GHz ständig um die iOS-Aufgabeschwelle (~−75) pendelt.
• Client-Aggressivität als Second Layer: 19:44:21 stand das Telefon bei −52 auf ap2-5G und floh 13 s später auf 2,4 (−77) — dasselbe Muster wie im Archiv-Fund E („Abbruch bei −47"). Steering-Objekte st-main/st-guest haben keine Schwellen (nur rrm/wnm) — der AP drängt nichts aktiv per BTM, die Entscheidungen trifft das iPhone.
• Mit ft=no (Dauerzustand seit 09-04) ist jeder Roam eine Voll-Reassoziation in Sekundenhöhe ⇒ genau darin sterben Anrufe.

Hebel-A-Machbarkeitsprüfung (Dry-Run, kein Write)

Ziel: 5-GHz-Boden für dirtyvader-main (reject unter ~−76), damit das Telefon an der Zellkante sofort endgültig auf 2,4 GHz committet statt zu thrashen.

Live + MikroTik-Doku verifiziert:

• signal-range wird kontinuierlich geprüft (Grace über allow-signal-out-of-range, Default 0s) — der Mechanismus trägt grundsätzlich.
• ABER: /interface/wifi/access-list hat kein band-Property. Band-Scoping nur über interface= möglich — und die cap-wifiN-Namen wechseln bei jedem CAP-Rejoin (Gotcha 2026-08-31): die Regel würde stillschweigend auf ein falsches Radio zeigen (im Worst Case ein 2,4-Master ⇒ Lockout-Schatten). Alternativen fallen alle durch:
  • Nur SSID scope (ohne Band): trifft auch 2,4 GHz — Schlafzimmer-Gegenmessung 08-22 (−84 dBm am Counter-AP) ⇒ Lockout, exakt das 08-22-Gegenargument.
  • Nur MAC scope (iPhone): trifft beide Bänder — das iPhone saß heute selbst bei −89 auf 2,4 GHz (19:01) ⇒ WiFi-Verlust in schwachen Räumen.
• Fazit: Der Band-Boden ist in der aktuellen wifi-qcom-Access-List nicht sauber ausdrückbar. Nicht umgesetzt; Dry-Run-Preview des Kandidaten gefahren, kein Apply.

Kandidat (NICHT angewendet, nur als Referenz wie er heute aussehen würde):

/interface wifi access-list add interface=cap-wifi1 ssid-regexp=dirtyvader-main \
    signal-range=-120..-76 action=reject comment="TP25-hebel-a-5g-boden"

(× cap-wifi1/2/3 — die drei 5G-Master — bricht bei jedem CAP-Rejoin)

Verbleibende Hebel:

1. ft=yes uniform auf sec-main — macht Roams nahtlos ⇒ Anrufe überleben das (verbleibende) Springen. Bewusste Aufweichung der 09-04-Entscheidung (ft=no), Fund-E-Ursache (7.24.1) ist längst behoben, FT-Flotte uniform. Ein Config-Weg: Template + Compliance + Transaktion.
2. Deckungsfix (TP25 Variante 3) — der eigentliche Hebel: ein AP muss an der Terrasse eindeutig stärker sein als alle anderen. Bemerkenswert: ap1-5G erreichte die Terrasse heute mit −64 (besser als ap2-5G mit −78) — ap1 sitzt bereits auf der Band-B-Liste 5260/5280.
3. Monitoring: wireless-Logging läuft persistent; das Flapping ist damit künftig rückwirkend diagnostizierbar.

Nachweise

• Live-Log am Manager: 43 + 18 + 8 Zeilen wireless,info zu F2:62:4C:E1:AF:09, 18:53–19:56.
• 1-s-Sampling: zwei 18-Sekunden-Loops (:for am Manager, Registration-Table), 20:01:44–20:02:26.
• Monitor-Reads: cap-wifi1 → 5300/ax/Ce/DI tx-power 18; cap-wifi6 → 2462/ax tx-power 15.
• Doku-Verifikation Access-List: help.mikrotik.com/docs/display/ROS/Wifi (signal-range kontinuierlich, kein band-Property, first-match-wins, kein impliziter Reject).

Offen / nächste Schritte

1. Entscheidung Christoph: ft=yes ja/nein (Hebel 1 oben) — ich lege dazu auf Go den GC-ConfigPlan als Dry-Run vor.
2. Deckungsfix-Terminierung (Variante 3 / ap1-Endausbau) — TP25 bleibt offen.
3. CLAUDE.md-Drift „ap1 FUNKSTILL" beim nächsten CLAUDE.md-Edit korrigieren (nur Vermerk hier, kein stiller Fix).
4. Gitea-TP25-Issue #17 hat einen Kommentar mit diesem Befund erhalten.
5. 🔴 Sicherheitsvorfall dieser Session: durch einen Env-Parse-Fehler stand der GITEA_ACCESS_TOKEN in einer URL im Traceback — Token ist als kompromittiert zu betrachten und zu rotieren (neues Token erzeugen, ~/.hermes/.env aktualisieren, altes widerrufen). Siehe Merkregel-Klasse „Werte nie suchen, um sie zu sehen".