TP25 Fund E wieder geoeffnet + WLAN-Logging persistent (27. ComplianceRule system-logging)

Auslöser war eine unabhaengige Meldung: seit Tagen/Wochen verliert das iPhone den
WiFi-Link bei gutem Signal und landet auf Mobilfunk. Auf Mobilfunk zu fallen ist KEIN
Roaming-Problem -- bei schlechtem Roaming bliebe das Telefon im WLAN und waere nur
langsam. Es heisst, die Assoziation ist gestorben und die Neuanmeldung gescheitert.

Der Manager-Log zeigt dasselbe iPhone (F2:62:4C:E1:AF:09) mit 16 Bandwechseln in 20
Minuten zwischen ap3s 5-GHz- und 2,4-GHz-Radio, zweimal im Abstand von einer Sekunde,
bei -53..-81 dBm -- kurz darauf dasselbe an ap2. Also nicht ap3-spezifisch.

Das stand schon im Repo: TP25 Fund E beschreibt es seit dem 2026-08-20, mit derselben
MAC und der Zeile "disconnected, not responding, signal strength -47" -- Abbruch bei
ausgezeichnetem Signal. Fund E war zurueckgestellt mit der Auflage "erst wieder
aufgreifen, wenn ein Sticky-Fall erneut gemessen ist". Die ist eingetreten. Das ist
heute der zweite Fall (nach dem TP25-Kanalplan fuer ap3), in dem eine fertige Analyse
im TP-Body stand und ich sie erst nach einer Extrarunde gefunden habe.

Der eigentliche Mangel war aber die Beweislage: `wireless` lief NUR nach action=memory,
nur `firewall` ging in den Kollektor. Der Ringpuffer fasste 75 Zeilen und war von einer
Stunde ap3-Arbeit fast ueberschrieben -- rueckwirkend war nichts diagnostizierbar.

Jetzt: zwei Regeln am Core (topics=wireless und topics=caps) in denselben Kollektor wie
TP5 (10.40.20.18:514). Gegenprobe auf beiden Seiten -- 32 Zeilen liegen bereits im
Tagesfile, inkl. `associated` (debug) und `connected` (info).

Und unter Drift-Kontrolle, denn /system logging stand unter KEINER der 26 Rules und gar
nicht im Template: neue ComplianceFeature/Rule `system-logging` (Muster: TP6 /queue,
TP26 /ip firewall filter), Template-Block [6a2] nur im Core-Zweig -- RouterOS exportiert
Defaults nicht, auf ap1/ap2/ap3/branch sind Soll und Ist beide leer.
Compliance 130/130 -> 135/135, 0 Drifts. Die Zahl MUSS sich bewegen: eine
gleichbleibende Zahl nach dem Hinzufuegen einer Regel waere ein Befund, kein Erfolg.

Zwei RouterOS-Fallen, beide als Gotcha in CLAUDE.md:
- Der Topic heisst `wireless`, NICHT `wifi` -- auch auf dem neuen wifi-qcom-Stack.
  Ein geratenes topics=wifi waere wirkungslos geblieben.
- RouterOS UND-verknuepft Topics innerhalb EINER Regel (`info,!firewall` = info UND
  NICHT firewall). `topics=wireless,caps` haette NICHTS gematcht -> zwei Regeln.

Recherche-Ergebnis gegen die offizielle MikroTik-Doku, das meine eigene erste Hypothese
widerlegt: transition-threshold steht per Default auf -80 dBm (-time 10s,
-request-period 30s, -count 3), und unsere Steering-Objekte setzen davon nichts. Bei
-53..-74 dBm wird das iPhone gar nicht Transition-Kandidat -- unsolicited BTM scheidet
als Treiber weitgehend aus. Die vielzitierte WPA3/802.11r-Inkompatibilitaet steht NICHT
in der Doku (dort nur: FT geht nicht ueber OWE); sie bleibt Hypothese.

BEWUSST NICHT geaendert: kein einziger Funk-Parameter. Drei Hebel sind dokumentiert und
priorisiert -- (1) 2g-probe-delay=yes, kann keinen Client stranden lassen, (2)
ft-over-ds=no, nimmt die Aenderung vom 2026-08-17 zurueck, (3) signal-range-Boden, der
invasivste und einzige, der Clients aussperren kann. Einzeln, je als Transaktion, erst
mit Daten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

nautobot/mikrotik_routeros.j2

@@ -160,6 +160,27 @@
 /system ntp client servers add address=at.pool.ntp.org
 /system ntp server set enabled=yes
 
+# [6a2] LOGGING — Beweissicherung, kein Betriebsdetail. TP25 Fund E, 2026-08-30.
+#
+#      Bis dahin liefen `wireless`-Logs NUR nach `action=memory`; nur `firewall` ging in den
+#      Kollektor. Der Ringpuffer fasste 75 Zeilen und war von einer Stunde Arbeit fast
+#      ueberschrieben -- ein seit Wochen gemeldeter iPhone-Abbruch war rueckwirkend deshalb
+#      nicht diagnostizierbar. Die zwei neuen Zeilen sind die Datengrundlage fuer die
+#      Entscheidung ueber die Steering-Hebel (2g-probe-delay / ft-over-ds / signal-range).
+#
+#      ⚠️ Der Topic heisst `wireless`, NICHT `wifi` -- auch auf dem neuen wifi-qcom-Stack
+#         (am Geraet nachgelesen). Ein geratenes `wifi` waere wirkungslos geblieben.
+#      ⚠️ RouterOS UND-verknuepft Topics innerhalb EINER Regel (`info,!firewall` = info UND
+#         NICHT firewall). `topics=wireless,caps` haette NICHTS gematcht -> zwei Regeln.
+#      📌 Nur der Core traegt hier Zeilen: RouterOS exportiert Defaults nicht, und unter
+#         CAPsMAN fuehrt ohnehin der MANAGER die Roaming-Events -- die CAPs loggen lokal nichts.
+#         Auf ap1/ap2/ap3/branch sind Soll und Ist beide leer, also compliant.
+/system logging action add name=tp5syslog remote=10.40.20.18 target=remote
+/system logging set 0 topics=info,!firewall
+/system logging add action=tp5syslog topics=firewall
+/system logging add action=tp5syslog comment="TP25 Fund E: WLAN-Roaming/Disconnects dauerhaft in den Kollektor" topics=wireless
+/system logging add action=tp5syslog comment="TP25 Fund E: CAP-An-/Abmeldungen dauerhaft in den Kollektor" topics=caps
+
 # [6b] WLAN — CAPsMAN. Seit TP28 (2026-08-17) ist der Core der Manager und ap1/ap2
 #      sind reine CAPs. Die fuenf wifi-*-ComplianceFeatures gehoeren deshalb HIERHER
 #      und nicht mehr in den AP-Zweig; auf den APs ist die entsprechende Config
@@ -247,11 +268,16 @@
 #            --scope wifi-access-list --change-id TEST-... --expires JJJJ-MM-TT
 #
 #      🔴 Hier landet TP25 **Fund E** (`signal-range`-Boden gegen klebende Clients),
-#      sobald er entschieden ist. Stand 2026-08-22 ist er es NICHT: der Sticky-Client
-#      vom 08-20 reproduzierte sich beim Rundgang am 08-22 nicht, und in den schwachen
-#      Raeumen gibt es keinen besseren AP, auf den ein Boden steuern koennte. Ein
-#      voreilig gesetzter Boden verschlechtert die Terrasse, statt zu helfen.
-#      Vor dem Eintragen also: Sticky-Fall erneut messen. Siehe teilprojekte.md TP25.
+#      sobald er entschieden ist. Die alte Auflage lautete "vor dem Eintragen den
+#      Sticky-Fall erneut messen" -- das ist am 2026-08-30 passiert: dasselbe iPhone
+#      machte 16 Bandwechsel in 20 Minuten bei -53..-81 dBm, erst an ap3, dann an ap2.
+#      Fund E ist damit WIEDER OFFEN.
+#      Eingetragen wird hier trotzdem NICHTS, und zwar bewusst: ein signal-range-Boden
+#      ist der invasivste der drei Hebel und kann Clients AUSSPERREN -- genau das war
+#      08-22 das Gegenargument (in den schwachen Raeumen gibt es keinen besseren AP,
+#      auf den ein Boden steuern koennte). Erst kommen (1) `2g-probe-delay=yes` und
+#      (2) `ft-over-ds=no`, jeder einzeln und als Transaktion, mit dem seit 2026-08-30
+#      laufenden wireless-Logging als Messgrundlage. Siehe teilprojekte.md TP25 Fund E.
 
 # Kanonischer Mgmt-Nummernplan (User-Bestaetigung 2026-08-13, verbindlich):
 #   core .99.1 | branch .99.2 | ap1 .99.11 | ap2 .99.12