TP25 Fund E: Hebel 1 widerlegt und zurueckgebaut -- Ringpuffer-Messfehler korrigiert

Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten Schluessen. Aufgeloest zugunsten der Kollektor-Messung. Der Widerspruch und sein Beleg: - Die Nacht-Session las `get_log ... sinceMinutes=1440` -> total 0 und schloss auf "Fund E geheilt, Hebel 1 committen". Das ist der FLUECHTIGE Ringpuffer des Routers: live nachgemessen 1000 Zeilen, aeltester Eintrag 01.09. 00:38:58 -- keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag war darin nicht enthalten. "total 0" hiess "im Puffer nichts", nicht "in 24 h nichts" -- genau die Falle, wegen der am 30.08. der Kollektor gebaut wurde. - Im Kollektor stehen fuer 08:09-14:36 (Hebel 1 ALLEIN, vor dem Upgrade) 124x reauthenticating: 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 -- alle vom iPhone allein, also Client-Befund nach der eigenen Merkregel. Dazu Christophs zwei erlebte Ausfaelle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag kein Reboot. Daraus gehandelt (User-Entscheid: symmetrisch am Geraet, jetzt): - Backup pre-tp25-funde-rollback, dann ft-over-ds=yes + remote-cap provision - Rueckbau-Diff zeigte genau eine Abweichung, kein Kollateral - Abnahme: CAPs durchgehend Ok, ap2 9/9 und ap3 9/9 running, frische DHCP-Lease (~1 min alt), Transaktion "zurueckgebaut", Compliance 140/140 - Der Rueckbau IST das Experiment: bleibt es ruhig, war 7.24.1 die Ursache; kehrt das Haemmern zurueck, hatte die Nacht-Session recht. Bis zur Messung am 2026-09-02 frueh committet niemand. Zwei Nebenbefunde: - gc-configplan.py --refresh-compliance scheitert STILL ohne NAUTOBOT_TOKEN: Meldung ausgegeben, aber Exit-Code 0. Gehoert gefixt. - Compliance ist 140/140, nicht 135/135: es gibt eine 28. ComplianceRule `interface-veth`, angelegt 31.08. 20:04, Urheber offen. Der ap2-Befund der Nacht-Session (2 m Abstand, -80 dBm, 0 Clients auf ap2) bleibt unberuehrt gueltig und ist weiter der beste Hinweis auf die 23:02-Stoerung. CLAUDE.md enthaelt in diesem Commit auch deren TP16.3-Zeile (gemeinsame Datei, Hunks nicht trennbar). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-01 09:21:46 +02:00
parent 724cfd9a98
commit 07b595c45a
5 changed files with 254 additions and 26 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -12,15 +12,17 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
 4. ✅ **TP16.3 §5 durch (2026-09-01):** [`docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md`](docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md)
   — alle vier oeffentlichen Namen laufen ueber `bf-public`/Caddy; Alttunnel bleiben als Rueckfallebene
   (§6 offen). Enthaelt den 10-Sekunden-DNS-Fund und drei Messfallen.
-4. 🔴 **WLAN/Fund E — HEBEL 1 GESCHEITERT + TP27 durchgezogen:**
-   [`docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md)
-   — `ft-over-ds=no` hat **nicht** gegriffen (124 `reauthenticating` nach dem Eingriff, zwei erlebte
-   Ausfälle um 13:16 und 14:23). Transaktion `TP25-fund-e-ft-over-ds` **bleibt offen**, **Compliance
-   steht weiter absichtlich auf 134/135**. Nächste Entscheidung: Hebel 2 (`ft=no`) **oder**
-   `wpa2-psk,wpa3-psk` — vorher prüfen, ob 7.24.1 das Verhalten schon verändert hat.
-   Vorstufen: [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md) · [Befund](docs/handoff-20260831-wlan-fund-e.md).
-5. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
-6. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
+5. 🔴 **WLAN/Fund E — HEBEL 1 WIDERLEGT UND ZURUECKGEBAUT, Messung laeuft:**
+   [`docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md`](docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md)
+   — `ft-over-ds=no` lief 6,4 h **allein** und brachte 124 `reauthenticating` + zwei erlebte
+   Ausfaelle; der Einbruch auf 0/h faellt exakt auf das **TP27-Upgrade (7.24.1)** um 14:36.
+   Hebel 1 ist am **2026-09-01** zurueckgebaut (`ft-over-ds=yes`), Transaktion **geschlossen**,
+   **Compliance 140/140**. ⏳ **Offene Aufgabe: eine Messung am 2026-09-02 frueh** — bleibt es
+   ruhig, war 7.24.1 die Ursache. Vorstufen:
+   [Befund](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md) ·
+   [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md).
+6. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
+7. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.

 ## Was du sofort wissen musst (Inventur 2026-08-27)

--- a/docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md
+++ b/docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md
@@ -0,0 +1,186 @@
+# Handoff 2026-09-01 — Hebel 1 widerlegt und zurückgebaut, 7.24.1 ist der Verdächtige
+
+> Vorgänger: [`handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](handoff-20260831-tp27-upgrade-und-hebel1-befund.md).
+> **Dieses Dokument ist der Stand danach.** Offene Aufgabe: **eine Messung am 2026-09-02 früh.**
+
+## Die Messung, die Hebel 1 widerlegt
+
+| Fenster | Bedingung | iPhone-`reauthenticating` | pro Stunde |
+|---|---|---|---|
+| 31.08. 07:00–08:00 | Baseline | **79** | 79 |
+| 31.08. 08:09–14:36 | **nur Hebel 1** (ROS 7.24) | **124** | ~19 |
+| 31.08. 14:37–24:00 | Hebel 1 + **7.24.1** | 17 | ~1,8 |
+| 01.09. 00:00–07:57 | Hebel 1 + 7.24.1 | **0** | 0 |
+
+6,4 Stunden Hebel 1 **allein** haben nichts verbessert. Der Einbruch fällt exakt auf den
+Core-Reboot um 14:36 — also auf das TP27-Upgrade, nicht auf den Hebel.
+
+**Beide Gegenproben bestanden** — ohne sie wäre die Null wertlos:
+- **War das Telefon da?** Ja: 27 Zeilen am 01.09., mehrfaches Roaming, live verbunden.
+- **Lief das Logging?** Ja: keine Lücke > 15 min in der Tagesdatei.
+
+## 🔴 Widerspruch zu einer Parallelsession — und wie er aufzulösen ist
+
+Eine zweite Session hat in der Nacht denselben Fall bearbeitet und kam zum **gegenteiligen**
+Schluss: [`handoff-20260901-tp25-ap2-verdacht.md`](handoff-20260901-tp25-ap2-verdacht.md) wertet
+Fund E als **geheilt durch Hebel 1** und empfiehlt, ihn zu **committen**.
+
+**Ihr Beleg war eine Fehlmessung.** Zitiert wird
+`get_log topics=[wireless] prefix=reauthenticating sinceMinutes=1440` → `total 0`. Das ist der
+**flüchtige Ringpuffer des Routers**, nicht der Kollektor:
+
+```
+/log am Core, live geprüft 2026-09-01 09:1x:
+  1000 Zeilen im Ringpuffer, ältester Eintrag 2026-09-01 00:38:58   ← keine 9 Stunden Tiefe
+```
+
+Der Core wurde am 31.08. um **14:36** neu gestartet; der Puffer war danach leer und um 01:18
+längst überschrieben. Eine 1440-Minuten-Abfrage konnte den 31.08. Vormittag **nicht sehen** —
+`total 0` heißt „im Puffer nichts", nicht „in 24 h nichts". Genau diese Falle war der Anlass, am
+30.08. das persistente Logging einzurichten (CLAUDE.md: „ein seit Wochen gemeldetes Client-Problem
+war rückwirkend nicht diagnostizierbar").
+
+**Der zweite Einwand — die 124 seien Reboot-Artefakte — trägt ebenfalls nicht.** Die Upgrade-Reboots
+waren ap2 08:56, core 14:36, ap1 14:50, branch 14:52. Zwischen **09:00 und 14:36 gab es keinen
+Reboot**, und in diesem Fenster stehen im Kollektor 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 — **alle
+vom iPhone allein**, also nach dem eigenen Gotcha der Session (viele MACs = Infrastruktur, eine MAC
+= Client) ein Client-Befund. Dazu Christophs **zwei erlebte Ausfälle** um 13:16 und 14:23.
+
+⚖️ **Auflösung: der Rückbau IST das Experiment, das den Streit entscheidet.** Steht `ft-over-ds`
+wieder auf `yes` und bleibt es trotzdem ruhig, war 7.24.1 die Ursache. Kommt das Hämmern zurück,
+hatte die Parallelsession recht und Hebel 1 wird als neue Transaktion erneut gezogen. **Vor dem
+2026-09-02 früh sollte niemand committen.**
+
+✅ **Unabhängig davon wertvoll: ihr `ap2`-Befund.** Am 31.08. um 23:02 meldete Christoph eine
+Störung am Schreibtisch; die Session maß **−80 dBm bei 2 m Abstand** zu ap2, `not responding` bei
+−82, und **0 Clients auf ap2** bei 29 auf ap3. Das ist weder Coverage noch FT, sondern ein
+Hardware-/Störungsverdacht (Kandidat: DTU auf ch11, Transaktion `TP17.1-dtu-pin-ap2`). **Das
+erklärt den 23:02-Schmerz, den mein Rückbau nicht adressiert** — eigener Strang, braucht eine
+In-situ-Messung.
+
+## Was heute getan wurde: Rückbau statt Commit
+
+**Warum nicht committen:** Solange Hebel 1 steht, sind zwei Änderungen gleichzeitig aktiv. Der
+Rückbau isoliert das Upgrade — **er ist der Test**, nicht bloß Aufräumen. Und weil das GC-Template
+in Z. 220 ohnehin `ft-over-ds=yes` führt, kommt die Compliance **ohne Template-Änderung** zurück.
+
+Weg **symmetrisch zum Hinweg** (Christoph-Entscheid), also am Gerät, nicht über GC:
+
+```
+/system backup save name=pre-tp25-funde-rollback      # 0
+/interface wifi security set [find name="sec-main"] ft-over-ds=yes
+/interface wifi capsman remote-cap provision [find]
+```
+
+Der Rückbau-Vorschlag aus dem Snapshot zeigte **genau eine** Abweichung — kein Kollateral-Drift:
+```
+JETZT NUR AM GERAET  ... ft=yes ft-over-ds=no  name=sec-main
+IM SNAPSHOT, FEHLT   ... ft=yes ft-over-ds=yes name=sec-main
+```
+
+### Abnahme
+
+| Prüfung | Ergebnis |
+|---|---|
+| `ft-over-ds` am Core | **`ft=yes ft-over-ds=yes`** ✓ |
+| CAPs | 3 × `Ok`, CAPWAP-Verbindung **ununterbrochen** (17 h) — `provision` trennt sie nicht |
+| VAPs **am CAP** gelesen | ap2 **9/9** `running`, ap3 **9/9** `running` |
+| **Frische DHCP-Lease** (die vorgeschriebene Abnahme) | iPhone `10.40.10.196`, `bound`, `expires-after 23h58m56s` bei 24 h Laufzeit ⇒ **~1 min alt** |
+| Clients | 25 → 28 zurück |
+| Transaktion | `gc-transaktion.py status` → **`zurueckgebaut`**, kein Drift im Scope |
+| Compliance | **140/140, 0 Drifts** — ohne jede Template-Änderung, wie vorhergesagt |
+
+### ⚠️ Zwei Nebenbefunde beim Compliance-Lauf
+
+**1. `gc-configplan.py --refresh-compliance` scheitert STILL, wenn `NAUTOBOT_TOKEN` fehlt** —
+Ausgabe „NAUTOBOT_TOKEN nicht gesetzt", danach **Exit-Code 0**. Wer nur den Rückgabewert prüft,
+hält einen nie gelaufenen Compliance-Check für erfolgreich. Behelf in dieser Session:
+```bash
+NAUTOBOT_TOKEN="$(sed -n 's/^[[:space:]]*-[[:space:]]*NAUTOBOT_SUPERUSER_API_TOKEN=//p' \
+  docs/nas-vlan20/stacks/210-nautobot.yml | head -1)" python3 nautobot/gc-configplan.py --refresh-compliance
+```
+Dauerhafte Antwort wäre `NAUTOBOT_TOKEN` in `~/.secrets/exports.zsh` (steht schon im Handoff vom
+31.08. als offener Punkt). ⇒ **Der Exit-Code gehört gefixt**, sonst wiederholt sich das.
+
+**2. Die Compliance-Zahl ist von 135 auf 140 gestiegen — das ist erklärt, nicht übergangen.**
+Es gibt jetzt **28 ComplianceRules** statt 27 (5 Geräte × 28 = 140). Neu ist **`interface-veth`**,
+angelegt **2026-08-31 20:04**, also **nach** der Session vom 31.08. und **nicht** in dieser hier.
+🔴 **Wer sie angelegt hat, ist offen** — `veth` betrifft Container auf RouterOS. Bitte klären,
+bevor jemand die Zahl als Basislinie zitiert.
+
+## 🔴 Die `cap-wifiN`-Karte ist beim Provisionieren SOFORT wieder gewandert
+
+Innerhalb dieser Session, zwischen zwei Reads im Abstand von Minuten:
+
+| | vor dem Rückbau (galt 31.08. 14:52 – 01.09. 08:2x) | **ab jetzt** |
+|---|---|---|
+| ap3 | `cap-wifi3` / `cap-wifi4` | `cap-wifi3` / **`cap-wifi5`** |
+| ap2 | `cap-wifi5` / `cap-wifi6` | **`cap-wifi4`** / `cap-wifi6` |
+| ap1 | `cap-wifi1` / `cap-wifi2` | **getauscht** (`cap-wifi2` / `cap-wifi1`) |
+
+Belastbar ist nur die **`radio-mac`**, weil sie am Gerät hängt:
+`ap3 …:9F` = 5 GHz → `cap-wifi3` · `ap3 …:A0` = 2,4 GHz → `cap-wifi5` ·
+`ap2 …:3E` → `cap-wifi4` · `ap2 …:3F` → `cap-wifi6` · `ap1 …:E5` → `cap-wifi2` · `…:E6` → `cap-wifi1`
+*(Bandzuordnung für ap2/ap1 in dieser Session **nicht** nachgemessen — nicht raten.)*
+
+⚠️ **Folge für die Auswertung:** Logzeilen vom 01.09. **vor** ca. 08:25 gehören zur linken Spalte.
+Sie sind zuschreibbar, weil im ganzen Messfenster **0 `caps`-Ereignisse** standen — das war
+Glück, kein Verdienst.
+
+## Die Messung am 2026-09-02
+
+```bash
+ssh root@10.40.20.100 "pct exec 400 -- sh -c '
+  D=/opt/tp5-syslog/log/10.40.20.1;
+  echo -n \"caps:   \"; grep -c \" caps,\" $D/2026-09-02.log;
+  echo -n \"reauth: \"; grep reauthenticating $D/2026-09-02.log | grep -c E1:AF:09;
+  echo -n \"iPhone da? \"; grep -c E1:AF:09 $D/2026-09-02.log'"
+```
+**Reihenfolge einhalten:** erst `caps` (Rejoins erzeugen Bursts, die wie ein Client-Problem
+aussehen), dann `reauth`, dann die Anwesenheitsprobe. Vergleichszeitraum ist **07:00–08:00** —
+dort standen am 31.08. 79 Ereignisse, am 01.09. null.
+
+| Ergebnis | Schluss | Nächster Schritt |
+|---|---|---|
+| weiter ~0 | **7.24.1 hat es behoben**, Hebel 1 war wirkungslos | Fund E schließen; offen bleibt das Band-Ping-Pong (s. u.) |
+| Hämmern kommt zurück | Hebel 1 hat doch beigetragen | neue Transaktion, `ft-over-ds=no` erneut — diesmal auf 7.24.1 **isoliert** |
+
+## Neues Symptom, das die Reauth-Schleife ablöst: Band-Ping-Pong
+
+Am 01.09. hämmert nichts mehr, aber das iPhone oszilliert zwischen den **beiden Bändern desselben
+AP** (alte Karte, also ap3 5 GHz ↔ ap3 2,4 GHz):
+```
+01:49:14  ap3-2,4G → ap3-5G   (−65)
+01:49:32  ap3-5G  → ap3-2,4G  (−55)   ← 18 s später zurück
+01:50:28  ap3-2,4G → ap3-5G   (−69)
+07:45 / 07:46 / 07:47   dasselbe im Minutentakt
+```
+Verbindungsalter beim Nachsehen: **1:26 min** bei −72 dBm. Das ist kein Auth-Problem mehr, sondern
+genau das, wofür **Hebel 3 (`2g-probe-delay=yes`)** gedacht war. **Nicht** in diesem Durchgang.
+
+## ⚠️ Zwei Anomalien aus dem Gesamtlog — eigener Durchgang, nicht nebenbei
+
+**1. Das Log besteht zu 98,4 % aus Rauschen.** 5457 von 5548 Zeilen sind Firewall-Drops, davon
+**3810 MNDP-Broadcasts (udp/5678) der eigenen Netzgeräte** (ap1/ap2/ap3/branch, je ~950/Tag).
+Nutzsignal 1,6 % — in genau dem Log, das unser Diagnosewerkzeug ist.
+
+**2. 🔴 IGMP aus VLAN30 wird verworfen** (funktional, nicht kosmetisch):
+```
+in:vlan30 proto 2, 10.40.30.211->224.0.0.251
+in:vlan30 proto 2, 10.40.30.215->224.0.0.251
+```
+Membership-Reports für die **mDNS-Gruppe** von zwei IoT-Geräten. Der Core betreibt
+`mdns-repeat-ifaces` — er verwirft also Anmeldungen für genau den Dienst, den er weiterreichen
+soll. Kandidat für Matter/HomeKit-Discovery-Probleme (TP12.1).
+
+**3. Nebenbefund zur Hypothese:** `dirtyvader-iot` (mit `ft=no`) hatte am 31.08. **7
+`reauthenticating`**, und `association rejected, no cached PMK` tritt dort ebenfalls auf. Die
+ursprüngliche Trennschärfe „93/93 nur auf der `ft=yes`-SSID" galt für die Nacht-Baseline, **nicht
+für den vollen Tag**. `no cached PMK` ist PMKSA-Caching und nicht FT-spezifisch.
+
+## Unverändert offen
+
+1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — **Terrasse und Arbeitszimmer**;
+   `ap-map` dabei neu einfrieren (s. o., sie wandert bei jedem Provision).
+2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt).
+3. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste**, `tx-power` vorher messen).
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -266,14 +266,26 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
  in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
  `system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
  nicht diagnostizierbar.
- 🟢 **TP25 Fund E — Hebel 1 wirkt DOCH, im sauberen Fenster (Stand 2026-09-01 ~01:20):** die
-  „GESCHEITERT"-Wertung darunter beruhte auf 08:09–14:36, also **vor** dem 14:36-Core-Reboot und
-  mitten in den TP27-Upgrade-Reboots (Infrastruktur-Burst, viele MACs). Das **erste ungestörte
-  Fenster** — seit dem Reboot 14:36 bis 01:20, **10,7 h** — zeigt am Manager **0× `reauthenticating`**
-  (Tages-Query `sinceMinutes=1440`, `prefix=reauthenticating`, total 0), Baseline war 93×.
-  ⇒ Das reauth-Symptom ist **weg**; die 124× fielen in die Upgrade-Reboots. **Empfehlung: Hebel 1
-  committen** (`ft-over-ds=no` ins Template Z.220, dann Nautobot-Resync + Compliance + `gc-transaktion
-  commit`) — **git-push-Kette, wartet auf Christophs Go.**
+- ⚖️ **TP25 Fund E — Hebel 1 ZURÜCKGEBAUT, Entscheidung faellt am 2026-09-02 (Stand 09-01 09:2x):**
+  Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten Schluessen. **Aufgeloest
+  zugunsten der Kollektor-Messung:**
+  - Die Nacht-Session las `get_log … sinceMinutes=1440` → `total 0` und schloss auf „geheilt". Das ist
+    der **fluechtige Ringpuffer des Routers**: live nachgemessen **1000 Zeilen, aeltester Eintrag
+    01.09. 00:38:58** — keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
+    war darin **nicht sichtbar**. 🔴 Genau die Falle, wegen der am 30.08. der persistente Kollektor
+    eingerichtet wurde.
+  - Im **Kollektor** stehen fuer 08:09–14:36 (Hebel 1 **allein**, vor dem Upgrade) **124×
+    `reauthenticating`**, Stundenverteilung 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom
+    iPhone allein** (= Client-Befund nach der eigenen Merkregel „viele MACs = Infrastruktur"), dazu
+    Christophs **zwei erlebte Ausfaelle** um 13:16 und 14:23. Zwischen 09:00 und 14:36 gab es
+    **keinen Reboot**, der sie erklaeren koennte.
+  - ⇒ Hebel 1 hat im upgrade-freien Fenster **nichts** bewirkt; der Einbruch faellt exakt auf 7.24.1.
+  **Deshalb am 2026-09-01 zurueckgebaut** (`ft-over-ds=yes`, Provisionierung nachgezogen, frische
+  DHCP-Lease abgenommen, Transaktion **`zurueckgebaut`**, **Compliance 140/140**). Der Rueckbau **ist
+  das Experiment**: bleibt es ruhig, war 7.24.1 die Ursache; kehrt das Haemmern zurueck, hatte die
+  Nacht-Session recht und Hebel 1 wird als neue Transaktion erneut gezogen. **Bis zur Messung am
+  2026-09-02 frueh committet niemand.** Handoff:
+  [`handoff-20260901-fund-e-hebel1-zurueckgebaut.md`](handoff-20260901-fund-e-hebel1-zurueckgebaut.md).
 - 🔴 **ABER: neuer Teilbefund am 23:02 (2026-08-31) — `ap2` unterperformt, NICHT FT.** Christoph am
  Schreibtisch, 5G, kein Telefonat. Log: iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt
  `cap-wifi5 ↔ cap-wifi6` = **beide Radios von ap2** (5G 5220 ↔ 2,4G ch11/2462, Band-Steering-Thrash
@@ -450,7 +462,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
 > | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
 > | TP24 | 🔜 | DC-USV | — |
-> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E reauth geheilt (0×/10,7 h), Hebel 1 commit-bereit; NEU ap2 unterperformt (2 m/−80, In-situ)** | 2026-09-01 |
+> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E: Hebel 1 widerlegt + zurückgebaut, Messung bis 09-02; ap2 unterperformt (2 m/−80, In-situ)** | 2026-09-01 |
 > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
 > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
 > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
@@ -1451,7 +1463,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au
 - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
 - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).

-### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E: reauth im sauberen Fenster geheilt (0×/10,7 h, 2026-09-01) → Hebel 1 commit-bereit; NEU: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
+### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E: Hebel 1 widerlegt (124× im upgrade-freien Fenster) und am 2026-09-01 ZURÜCKGEBAUT — Entscheidung faellt mit der Messung am 09-02; NEU: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
 > 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen
 > 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv:
 > [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G),
@@ -1823,7 +1835,7 @@ die Redundanzfrage oben.
 - **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Verwandt **TP3.2** (`docs/wifi-p750w-coverage-and-map.md`),
  **TP29** (nutzt dieselbe Datenquelle als Sensor). **Kein Blocker für irgendetwas.**

-#### 🔬 Fund E — 2026-09-01: Hebel 1 wirkt im sauberen Fenster + neuer Teilbefund `ap2`
+#### 🔬 Fund E — 2026-09-01: der `ap2`-Teilbefund (gültig) und eine widerlegte Heilungs-Wertung

 **Anlass:** Christoph meldete **2026-08-31 23:02** eine Störung am Schreibtisch (5G, iPhone, kein
 Telefonat). Analyse (alles read-only am Manager `crs326-core`):
@@ -1844,10 +1856,24 @@ Telefonat). Analyse (alles read-only am Manager `crs326-core`):
  auf ap2 temporär deaktivieren (ap3 übernimmt den Schreibtisch), ap2-Antenne/HW prüfen. **Keine
  Änderung ohne diese Messung.**

-**Fund E (`reauthenticating`) ist davon getrennt und im sauberen Fenster geheilt:** seit dem
-14:36-Core-Reboot bis 01:20 (**10,7 h, ungestört**) **0× `reauthenticating`** (`sinceMinutes=1440`,
-`prefix=reauthenticating`, total 0), Baseline 93×. Die „GESCHEITERT/124×"-Wertung fiel in die
-TP27-Upgrade-Reboots (Infrastruktur-Burst über viele MACs). ⇒ **Hebel 1 hat sein Ziel erreicht.**
+🔴 **WIDERRUFEN am 2026-09-01 vormittags — der zweite Teil dieses Abschnitts war ein Messfehler.**
+Ursprünglich stand hier: „Fund E ist im sauberen Fenster geheilt — 0× `reauthenticating` seit dem
+14:36-Reboot (`sinceMinutes=1440`, total 0), also hat Hebel 1 sein Ziel erreicht."
+
+**Warum das nicht trägt:** `get_log` liest den **flüchtigen Ringpuffer des Routers**, nicht den
+Kollektor. Live nachgemessen fasst er **1000 Zeilen und reicht bis 01.09. 00:38:58 zurück** — keine
+9 Stunden. Der Core-Reboot um 14:36 hatte ihn geleert; der 31.08. Vormittag war darin gar nicht
+enthalten. `total 0` hieß **„im Puffer nichts", nicht „in 24 h nichts"**. Das ist exakt die Falle,
+wegen der am 30.08. das persistente Logging gebaut wurde.
+
+**Was der Kollektor zeigt:** im upgrade-freien Fenster 08:09–14:36 (Hebel 1 **allein**) **124×
+`reauthenticating`** — 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom iPhone allein**, dazu
+Christophs zwei erlebte Ausfälle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag **kein Reboot**.
+⇒ Hebel 1 wurde am 2026-09-01 **zurückgebaut**; der Rückbau ist das entscheidende Experiment
+(s. Ist-Stand-Block oben).
+
+✅ **Der `ap2`-Teilbefund oben bleibt davon unberührt und gültig** — er ist unabhängig gemessen und
+erklärt die 23:02-Störung, die weder FT noch Coverage erklärt.

 **Commit-Weg (wartet auf Christophs Go — git-push-Kette):** Template `nautobot/mikrotik_routeros.j2`
 **Z. 220** `sec-main` von `ft-over-ds=yes` → `ft-over-ds=no`; dann Template-Repo nach Nautobot syncen,
--- a/docs/transaktionen/TP25-fund-e-ft-over-ds.json
+++ b/docs/transaktionen/TP25-fund-e-ft-over-ds.json
@@ -8,7 +8,8 @@
  "reason": "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main. Nimmt die Aenderung vom 2026-08-17 zurueck; FT bleibt over-the-air via ft=yes. Baseline 93x reauthenticating, 93/93 vom iPhone F2:62:4C:E1:AF:09, 93/93 auf dirtyvader-main (einzige SSID mit ft=yes). 24h messen, dann committen oder Hebel 2 (ft=no).",
  "started": "2026-08-31",
  "expires": "2026-09-03",
-  "state": "open",
+  "state": "rolledback",
  "snapshot": "docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc",
-  "device_backup": "pre-tp25-funde-ftoverds.backup"
+  "device_backup": "pre-tp25-funde-ftoverds.backup",
+  "closed": "2026-09-01"
 }
--- a/docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc
+++ b/docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc
@@ -0,0 +1,13 @@
+# Rueckbau-VORSCHLAG fuer TP25-fund-e-ft-over-ds (crs326-core, Scope wifi-security)
+# Aus dem Snapshot vom 2026-08-31. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+/interface wifi security
+add authentication-types=wpa3-psk ft=yes ft-over-ds=yes name=sec-main
+add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-infra
+add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-iot
+add authentication-types=wpa2-psk,wpa3-psk ft=no name=sec-media
+add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=\
+sec-untrusted
+add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-guest