From 07b595c45aa9b994968fe7b57eb2305a90ba0c0c Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 1 Sep 2026 09:21:46 +0200 Subject: [PATCH] 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 --- CLAUDE.md | 20 +- ...ff-20260901-fund-e-hebel1-zurueckgebaut.md | 186 ++++++++++++++++++ docs/teilprojekte.md | 56 ++++-- .../transaktionen/TP25-fund-e-ft-over-ds.json | 5 +- .../TP25-fund-e-ft-over-ds.rollback.rsc | 13 ++ 5 files changed, 254 insertions(+), 26 deletions(-) create mode 100644 docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md create mode 100644 docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc diff --git a/CLAUDE.md b/CLAUDE.md index 74a6886..d49b0b0 100644 --- 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) diff --git a/docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md b/docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md new file mode 100644 index 0000000..5ff83a7 --- /dev/null +++ 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). diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 27eaa67..a6a167e 100644 --- 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, diff --git a/docs/transaktionen/TP25-fund-e-ft-over-ds.json b/docs/transaktionen/TP25-fund-e-ft-over-ds.json index 56f4a9d..151f19a 100644 --- 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" } diff --git a/docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc b/docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc new file mode 100644 index 0000000..9199fad --- /dev/null +++ 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