Files

Christoph Emsenhuber 05a3fd957f TP25 Fund E geschlossen: 7.24.1 war die Ursache, nicht ft-over-ds

Abschlussmessung 2026-09-02: reauthenticating 218->40->4 (09-02 nur 4 in
8,6 h, alle iPhone F2:62, 0 Ausfaelle). Vorbedingung geprueft (Core-Uptime
1d18h, caps joined=0 -> keine Reboot-Artefakte). Hebel 1 widerlegt+
zurueckgebaut, Hebel 2-4 entfallen, kein Geraete-Write (Compliance 140/140).
Offen bleibt nur ap2-Unterperformance.

- neu: docs/handoff-20260902-tp25-fund-e-messung.md
- teilprojekte.md: Quick-Index + Ist-Stand + TP25-Abschnitt + Hebel-Tabelle
- CLAUDE.md: Pflichtlektuere Punkt 5 auf geschlossen

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

2026-09-02 08:44:32 +02:00

3.3 KiB

Raw Blame History

Handoff 2026-09-02 — TP25 Fund E: die Abschlussmessung, und was sie entschieden hat

Kurz: Die für heute früh vorgemerkte Messung ist gelaufen. 7.24.1 hat den reauthenticating-Sturm aufgelöst, nicht ft-over-ds. Hebel 1 war widerlegt und ist zu Recht zurückgebaut; Hebel 2–4 entfallen. Fund E ist geschlossen — ohne Geräte-Write.

Was Fund E war

Ein reauthenticating-Sturm, sauber isoliert auf einen Client (iPhone F2:62:4C:E1:AF:09) und eine SSID (dirtyvader-main, die einzige mit ft=yes ft-over-ds=yes). Baseline: 93/93 auf genau diesem Client und dieser SSID. Hebel 1 (ft-over-ds=no) lief am 31.08. 6,4 h allein und machte es schlimmer (124 ≈ 19/h + 2 erlebte Ausfälle) → am 01.09. zurückgebaut, Transaktion TP25-fund-e-ft-over-ds geschlossen. Der Einbruch auf ~0/h fiel exakt auf das TP27-Upgrade 7.24.1 (Core-Reboot 31.08. 14:36).

Vorbedingung zuerst (CLAUDE.md-Gotcha: „grep caps + uptime vor Client-Diagnose")

Core-Uptime 1d18h → letzter Reboot 31.08. 14:36; kein Reboot am 01./02.09.
caps joined = 0 an beiden Tagen.
⇒ Die Zahlen unten sind echte Client-Ereignisse, keine Reboot-Artefakte.

Messung (Kollektor `/opt/tp5-syslog/log/10.40.20.1/`, via pve→`pct exec 400`)

Tag	reauth total	davon iPhone F2:62	distinct MACs	data loss / deauth	Kontext
08-31	225	218	6	(Upgrade+Hebel1)	Hebel-1-Fenster + 2 Upgrade-Reboots
09-01	44	40	4	0	7.24.1, Hebel 1 mittags zurückgebaut
09-02 (00:00–08:37)	4	4	1	0	7.24.1 + `ft-over-ds=yes`, sauberes Fenster

218 → 40 → 4. Am 09-02 vier isolierte Einzelereignisse (01:13, 02:00, 03:14, 08:01), kein Burst, alle dirtyvader-main (Interface cap-wifi3/cap-wifi6 — die cap-wifiN-Karte wandert, deshalb NICHT einem AP zugeschrieben). ≈ 0,46/h gegen Baseline 93 bzw. Hebel-1 19/h.
Der iPhone ist präsent und stabil — er verbindet und erzeugt die 4 Zeilen, ist also nicht „still, weil abwesend".
Die 97 association rejected am 09-01 fallen auf den Rollback-/Re-Provisioning-Vorgang (viele MACs = Infrastruktur, per Gotcha), nicht auf einen Client; am 09-02 nur 5.

Schluss & Entscheidung

7.24.1 war die Ursache/der Fix, nicht ft-over-ds. Der Restwert (~0,5/h isolierte Einzel-Reauth eines iPhones, 0 Ausfälle) ist normales iOS-Roaming, kein Defekt. Hebel 2–4 (ft=no, 2g-probe-delay, signal-range) werden NICHT gezogen. Fund E geschlossen.

Kein Geräte-Write: Sollzustand steht bereits (sec-main = ft=yes ft-over-ds=yes, Flotte 7.24.1, Transaktion zurueckgebaut, Compliance 140/140).

Bleibt offen (nicht Fund E)

ap2 unterperformt (2 m / −80 dBm, 23:02-Befund) — eigener In-situ-Unterpunkt in TP25, kein FT-/Auth-Thema. TP25 bleibt deshalb als Sammel-TP offen.

Merkregel bestätigt

Der Fall ist ein Lehrstück für zwei CLAUDE.md-Regeln: (a) Reboots zuerst ausschließen hätte am 31.08. verhindert, den Upgrade-Reboot-Burst für Client-Instabilität zu halten; (b) eine Drift/ein Symptom im offenen Versuch sieht aus wie ein Defekt — Hebel 1 „verbesserte auf 0/h" war in Wahrheit das parallele Upgrade. Die einzelne Messung nach dem Rückbau hat beides getrennt.

3.3 KiB Raw Blame History Unescape Escape