Stand der Parallelsession eingesammelt (TP39 archiviert, TP41-Backup, TP25 ap2-Verdacht)
Diese Aenderungen stammen NICHT aus dieser Session. Sie lagen seit 01:41 uncommittet im gemeinsamen Working Tree, in dem parallel mehrere Sessions schreiben -- jedes read-modify-write haette sie stillschweigend ueberschreiben koennen. Daher hier unveraendert gesichert, bevor irgendetwas anderes passiert. Inhalt: - TP39 (LXC-Hygiene pve) abgeschlossen und nach teilprojekte-archiv.md verschoben - TP41-Cloudflare-Backup unter docs/cf-backup/tp41-20260901/ - handoff-20260901-tp25-ap2-verdacht.md: Befund, dass ap2 unterperformt (iPhone 2 m entfernt, aber -80 dBm; 0 Clients auf ap2 gegen 29 auf ap3). Dieser Teil ist wertvoll und unabhaengig -- er erklaert Christophs 23:02-Stoerung vom 31.08. WARNUNG zum TP25-Teil: der hier eingesammelte Stand wertet Fund E als "Hebel 1 wirkt DOCH, commit-bereit". Diese Wertung ist ueberholt -- sie beruht auf einer Messung im fluechtigen Router-Ringpuffer. Korrektur folgt im naechsten Commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
54
docs/handoff-20260901-tp25-ap2-verdacht.md
Normal file
54
docs/handoff-20260901-tp25-ap2-verdacht.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Handoff 2026-09-01 — TP25: Fund E geheilt (sauberes Fenster) + neuer Verdacht `ap2`
|
||||
|
||||
**Kontext:** Christoph meldete um **2026-08-31 23:02** eine WLAN-Störung am Schreibtisch (5G, iPhone,
|
||||
kein Telefonat). Diese Session hat den Vorfall am Manager `crs326-core` analysiert (alles read-only)
|
||||
und dabei den Fund-E-Stand korrigiert. Parallel wurde TP39 abgeschlossen (eigener Strang, s. Archiv).
|
||||
|
||||
## Kernbefunde
|
||||
|
||||
### 1. Fund E (`reauthenticating`) ist geheilt — die „GESCHEITERT"-Wertung war kontaminiert
|
||||
- Core-Uptime `10h41m` @ 01:18 ⇒ letzter Reboot **14:36** (TP27-Upgrade). Der `caps`-Log endet um
|
||||
15:57; um 23:02 **kein** caps-Ereignis ⇒ kein Infrastruktur-/Reboot-Burst, echtes Client-Event.
|
||||
- **Tages-Query** `get_log topics=[wireless] prefix=reauthenticating sinceMinutes=1440` → **total 0**.
|
||||
Das erste ungestörte Fenster (14:36 → 01:20, **10,7 h**) zeigt **0× reauthenticating**; Baseline 93×.
|
||||
- Die im Vorgänger-Handoff notierten „124× nach dem Eingriff" fielen in die TP27-Upgrade-Reboots
|
||||
(viele MACs = Infrastruktur, CLAUDE.md-Gotcha). ⇒ **Hebel 1 (`ft-over-ds=no`) hat sein Ziel erreicht.**
|
||||
|
||||
### 2. Neuer Teilbefund: `ap2` unterperformt (das ist der 23:02-Schmerz, NICHT FT)
|
||||
AP-Karte (Manager, stabil seit Rejoin 15:57): `cap-wifi5/6 = ap2`, `cap-wifi3/4 = ap3`,
|
||||
`cap-wifi1/2 = ap1` (funkstill).
|
||||
|
||||
- 23:02: iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt `cap-wifi5 ↔ cap-wifi6` =
|
||||
**ap2s 5G (5220) ↔ ap2s 2,4G (ch11/2462)** — Band-Steering-Thrash auf **demselben** AP.
|
||||
`disconnected, not responding` um 22:37:40 (−76) und **23:01:00** (−82). Roam-Feldstärke −75…−88 dBm.
|
||||
- 🔴 **Christophs Fakt:** iPhone ↔ ap2 nur **2 m**, gleicher Raum, ap2 auf 2,3 m. Bei 2 m wären
|
||||
−35…−45 dBm normal. −80 auf 2 m ⇒ **kein Coverage-, kein FT-Problem**.
|
||||
- **0 Clients auf ap2 aktuell**, alle 29 auf ap3 → die Clients meiden ap2.
|
||||
- Verdacht: **ap2s Funk selbst** (RF/Antenne/HW) und/oder **DTU-Störung auf ap2/ch11**
|
||||
(Transaktion `TP17.1-dtu-pin-ap2`, `54:F2:9F:12:51:F0`, −59 dBm auf ap2s 2,4-Radio).
|
||||
|
||||
**In-situ-Diagnose nötig** (nachts nicht messbar, Phone idle auf ap3): Registration-Signal live prüfen,
|
||||
während ein Client auf ap2 hängt. Kandidaten-Eingriffe: DTU-Pin lösen/verlegen; `dirtyvader-main` auf
|
||||
ap2 temporär deaktivieren (ap3 übernimmt Schreibtisch); ap2-Antenne/HW prüfen. **Keine Änderung ohne
|
||||
diese Messung.**
|
||||
|
||||
## Offen / nächster Schritt
|
||||
|
||||
**Hebel 1 committen** (Transaktion `TP25-fund-e-ft-over-ds`, Scope `wifi-security`, Ablauf 2026-09-03).
|
||||
Der Commit ist eine **git-push-Kette** und wartet auf Christophs Go:
|
||||
|
||||
1. `nautobot/mikrotik_routeros.j2` **Z. 220**: `sec-main` `ft-over-ds=yes` → `ft-over-ds=no`.
|
||||
2. Template-Repo nach Nautobot syncen (Golden-Config-Git-Repository).
|
||||
3. `python3 nautobot/gc-configplan.py --refresh-compliance` (Backup → Intended → Compliance).
|
||||
4. `python3 nautobot/gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds`
|
||||
(verweigert, solange `wifi-security` noch driftet — deshalb Schritt 1–3 zuerst).
|
||||
|
||||
🔴 Schritt 1 ist ein `git push` (Backup-Guard + Christophs Commit-Hinweis-Regel) und Schritt 2–4 sind
|
||||
Live-Nautobot-Jobs — bewusst **nicht autonom** ausgeführt. Geräte-Backup `pre-tp25-funde-ftoverds.backup`
|
||||
liegt auf dem Core. `wifi-security` wird ohnehin **nicht deployt** (Passphrasen `<<REDACTED>>` im
|
||||
Template, Z. 189–196) — der Commit ist reine Soll↔Live-Angleichung, kein Geräte-Write.
|
||||
|
||||
## Werkzeug-Notiz
|
||||
- AP-Zuordnung: `/interface wifi radio print terse proplist=cap,radio-mac,interface` am Manager.
|
||||
- reauth-Zählung: `get_log` mit `prefix=reauthenticating` (nicht `list_wifi_interfaces` — leakt PSKs).
|
||||
- Kanäle: `/interface wifi print detail` je `cap-wifiN` (Frequenz + Band im `channel.`-Block).
|
||||
Reference in New Issue
Block a user