TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main, Messung laeuft
Ein Hebel, sonst nichts. 2026-08-31 08:09 am Manager crs326-core: /interface wifi security set [find name="sec-main"] ft-over-ds=no /interface wifi capsman remote-cap provision [find] ft=yes bleibt -- FT laeuft weiter over-the-air, nur nicht mehr over-the-DS. Nimmt exakt die Aenderung vom 2026-08-17 zurueck. Abnahme (Lease, nicht Registration-Table): - Manager, alle vier aktiven Master-VAPs cap-wifi3/4/5/6: ft=true ft-over-ds=false - alle 3 CAPs state=Ok, alle VAPs running=yes AM CAP gelesen - iPhone nach 71 s zurueck auf dirtyvader-main, frische Lease 10.40.10.196, auth-type=ft-wpa3-psk, -54 dBm; 30 Clients gesamt zurueck - Log 08:13:20 zeigt sauberes "roamed to" zwischen zwei APs -> Roaming intakt - Geraete-Backup vorher: pre-tp25-funde-ftoverds.backup Governance: Transaktion TP25-fund-e-ft-over-ds OFFEN (Scope wifi-security, Ablauf 2026-09-03). Compliance steht deshalb ABSICHTLICH auf 134/135; der Diff ist exakt ft-over-ds=yes->no, kein Kollateral-Drift durch die Re-Provisionierung. Das GC-Template wird erst beim COMMIT nachgezogen -- vorher gruen machen wuerde den laufenden Versuch unsichtbar machen, und gc-transaktion.py verweigert den Commit ohnehin, solange der Scope driftet. 135/135 kommt nach der Messung zurueck. Messstand nach 25 min: weiter 93, letzter reauthenticating 07:34:43 (vor dem Eingriff). Logging nachweislich lebendig (593 wireless-Zeilen heute, beide SSIDs). Noch kein Ergebnis, nur ein sauberer Schnitt. Drei Funde: - cap-wifiN-Karte hat sich beim Re-Provisionieren VERSCHOBEN: ap2 war 1/2 -> jetzt 3/5, ap3 war 5/6 -> jetzt 4/6, ap1 hat 1/2 bekommen. Wer die 07:xx-Zeilen gegen die neuen liest, ordnet dem falschen AP zu. - Korrektur am Vormittagsbefund: main unterscheidet sich in ZWEI Attributen, nicht einem -- es ist auch die einzige SSID ohne wpa2-psk. Die Kontrollgruppe trennt FT und WPA3-only nicht. Wenn Hebel 1 und 2 beide nichts bewegen, ist authentication-types der naechste Kandidat, NICHT signal-range. - gc-transaktion.py rief sshpass -p auf (Passwort in argv, Klasse vom 2026-08-22). Auf SSHPASS-Env + -e umgestellt, weil das Skript laufen musste. Fuenf weitere Dateien unter routeros/ haben dasselbe Muster und sind bewusst NICHT angefasst (Stop-Bedingung; gehoert zu TP30). Entwarnung: /export auf 7.24 gibt Passphrasen gar nicht aus (live geprueft), die Transaktionsakte im Git ist sauber. Nebenbei: .gitignore hatte docs/nas-vlan20/stacks/ MIT Schraegstrich -- im Worktree liegt dort ein Symlink auf den Haupt-Checkout, der war damit nicht ignoriert. Doku an allen drei Stellen nachgezogen (Quick-Index, TP25-Abschnitt, Ist-Stand-Block) plus CLAUDE.md-Pflichtlektuere und neuer Handoff mit Entscheidungstabelle fuer 09-01. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
140
docs/handoff-20260831-fund-e-hebel1-gezogen.md
Normal file
140
docs/handoff-20260831-fund-e-hebel1-gezogen.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# Handoff 2026-08-31 — TP25 Fund E: Hebel 1 ist gezogen, die Uhr läuft
|
||||
|
||||
> Vorgänger: [`handoff-20260831-wlan-fund-e.md`](handoff-20260831-wlan-fund-e.md) (Befund + Messrezept).
|
||||
> **Dieses Dokument ist der Stand danach.** Es gibt genau eine offene Aufgabe: **messen und entscheiden.**
|
||||
|
||||
## Was am 2026-08-31 um 08:09 passiert ist
|
||||
|
||||
**Eine** Änderung, sonst nichts:
|
||||
|
||||
```
|
||||
/interface wifi security set [find name="sec-main"] ft-over-ds=no # vorher: yes
|
||||
/interface wifi capsman remote-cap provision [find]
|
||||
```
|
||||
|
||||
`ft=yes` bleibt — Fast Transition läuft weiter **over-the-air**, nur nicht mehr **over-the-DS**. Das
|
||||
nimmt exakt die Änderung vom 2026-08-17 zurück, mehr nicht. **Kein weiterer Funk-Parameter ist
|
||||
angefasst worden** (Stop-Bedingung: wer zwei Hebel zieht, weiß hinterher nichts).
|
||||
|
||||
## Abnahme — was tatsächlich geprüft wurde
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Wirkt der Hebel? **am Manager, alle Master-VAPs** | `cap-wifi3/4/5/6` → `ft=true ft-over-ds=false`. `cap-wifi1/2` (= ap1) leer, weil ap1 funkstill ist. |
|
||||
| CAPs zurück? | alle drei `state=Ok` |
|
||||
| VAPs laufen? **am CAP gelesen**, nicht am Manager | ap2 und ap3: alle 9 Interfaces `running=yes` |
|
||||
| **Frische DHCP-Lease** (die vorgeschriebene Abnahme) | iPhone `F2:62:4C:E1:AF:09` nach 71 s wieder auf `dirtyvader-main`, `10.40.10.196`, **`auth-type=ft-wpa3-psk`**, −54 dBm |
|
||||
| Clients gesamt | 30 zurück |
|
||||
| Roaming funktioniert noch? | ja — Log zeigt um 08:13:20 ein sauberes `roamed to` zwischen zwei APs auf `main` |
|
||||
| Compliance | **134/135**, Diff **exakt** `ft-over-ds=yes → no`. **Kein Kollateral-Drift.** |
|
||||
|
||||
Geräte-Backup vor dem Eingriff: `pre-tp25-funde-ftoverds.backup` auf dem Core (08:07:58).
|
||||
|
||||
## 🔴 Warum Compliance auf 134/135 steht und das RICHTIG ist
|
||||
|
||||
Die Transaktion **`TP25-fund-e-ft-over-ds`** ist **offen** (Scope `wifi-security`, Ablauf
|
||||
**2026-09-03**). `gc-transaktion.py status` weist den einen Drift als **erwartet** aus — genau dafür
|
||||
gibt es das Werkzeug.
|
||||
|
||||
**Das Template wird bewusst NICHT vorher nachgezogen.** Wer es jetzt grün macht, macht den laufenden
|
||||
Versuch unsichtbar, und `status` kann ihn nicht mehr von einem Versehen unterscheiden. `gc-transaktion.py`
|
||||
erzwingt die richtige Reihenfolge ohnehin: es verweigert den Commit, solange der Scope driftet.
|
||||
**135/135 kommt beim Commit zurück** — nach der Messung, nicht davor.
|
||||
|
||||
## 🔴 Die `cap-wifiN`-Karte hat sich beim Re-Provisionieren VERSCHOBEN
|
||||
|
||||
Wer die Logs vom 31.08. auswertet und das übersieht, ordnet Ereignisse dem falschen AP zu:
|
||||
|
||||
| | vor 08:09 (Logzeilen 07:xx) | ab 08:09 |
|
||||
|---|---|---|
|
||||
| ap1 (funkstill) | — | `cap-wifi1` / `cap-wifi2` |
|
||||
| ap2 | `cap-wifi1` / `cap-wifi2` | `cap-wifi3` / `cap-wifi5` |
|
||||
| ap3 | `cap-wifi5` / `cap-wifi6` | `cap-wifi4` / `cap-wifi6` |
|
||||
|
||||
Gelesen mit `/interface wifi radio print` am Manager. Das ist dieselbe Instabilität, die
|
||||
[`tp25-walk-messung.sh`](tp25-walk-messung.sh) als `ap-map.txt` einfriert — hier von Hand.
|
||||
|
||||
## ⚠️ Korrektur am Befund vom Vormittag
|
||||
|
||||
Der Vorgänger-Handoff sagt, `main` unterscheide sich von den anderen fünf SSIDs in **genau einem**
|
||||
Attribut. **Live nachgelesen sind es zwei:**
|
||||
|
||||
```
|
||||
sec-main authentication-types=wpa3-psk ft=yes ft-over-ds=yes
|
||||
sec-infra … authentication-types=wpa2-psk,wpa3-psk ft=no
|
||||
```
|
||||
|
||||
`sec-main` ist **auch die einzige SSID ohne `wpa2-psk`**. Die Kontrollgruppe trennt FT und WPA3-only
|
||||
also **nicht** voneinander. Das ändert die Hebelreihenfolge nicht — die Hypothese nennt gerade die
|
||||
Kombination WPA3+FT — aber es ändert den Plan B:
|
||||
|
||||
⇒ **Wenn Hebel 1 und Hebel 2 (`ft=no`) beide nichts bewegen, ist der nächste Kandidat
|
||||
`authentication-types=wpa2-psk,wpa3-psk` auf `sec-main` — NICHT `signal-range`.**
|
||||
|
||||
## Die einzige offene Aufgabe: messen
|
||||
|
||||
```bash
|
||||
ssh root@10.40.20.100 "pct exec 400 -- sh -c 'cat /opt/tp5-syslog/log/10.40.20.1/2026-0*-*.log |
|
||||
grep reauthenticating | grep -oE \"([0-9A-F]{2}:){5}[0-9A-F]{2}\" | sort | uniq -c'"
|
||||
```
|
||||
|
||||
**Baseline: 93**, alle vom iPhone `F2:62:4C:E1:AF:09`, alle auf `dirtyvader-main`.
|
||||
Davon **79 am 31.08., sämtlich in Stunde 07**, der letzte um **07:34:43** — also **vor** dem Eingriff.
|
||||
Zwischen 08:00 und 08:15 kein einziges. **Das ist noch kein Ergebnis, nur der saubere Schnitt.**
|
||||
|
||||
Ein Gegencheck gehört dazu — er beweist, dass nicht einfach das Logging kaputt ist:
|
||||
|
||||
```bash
|
||||
ssh root@10.40.20.100 "pct exec 400 -- sh -c '
|
||||
grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | wc -l;
|
||||
grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | grep -oE \"\\(dirtyvader-[a-z]+\\)\" | sort | uniq -c'"
|
||||
```
|
||||
|
||||
### Die Entscheidung am 2026-09-01
|
||||
|
||||
| Messung | Schluss | Nächster Schritt |
|
||||
|---|---|---|
|
||||
| iPhone-`reauthenticating` **~0**, andere SSIDs unverändert | Hebel 1 hat gegriffen | Template `mikrotik_routeros.j2` Z. 220 auf `ft-over-ds=no` ziehen → `gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds` → Compliance zurück auf 135/135 |
|
||||
| Zahl **unverändert** | Hebel 1 hat **nicht** gegriffen | Rollback ODER stehen lassen und **Hebel 2 `ft=no`** als eigene Transaktion. Nicht beides gleichzeitig. |
|
||||
| Zahl runter, aber neue Ereignisse auf anderen SSIDs | Nebenwirkung | Rollback, dann neu bewerten |
|
||||
|
||||
Rollback-Weg (der Snapshot liegt bereit):
|
||||
`python3 nautobot/gc-transaktion.py rollback --change-id TP25-fund-e-ft-over-ds`
|
||||
— erzeugt einen **Vorschlag**, der gelesen werden will, und pusht bewusst nicht selbst.
|
||||
|
||||
## 🔧 Nebenbefund: `sshpass -p` in sechs Skripten
|
||||
|
||||
`nautobot/gc-transaktion.py` rief `sshpass -p <PW>` auf — das schreibt das Passwort in `argv`, wo es
|
||||
in `ps` und jedem argv-Trace steht. Das ist die Klasse, an der am 2026-08-22 das Core-Passwort
|
||||
verbrannt ist, und CLAUDE.md verbietet sie ausdrücklich. **In `gc-transaktion.py` behoben**
|
||||
(`SSHPASS`-Env + `-e`), weil das Skript für diese Aufgabe laufen musste.
|
||||
|
||||
🔴 **Fünf weitere Dateien haben dasselbe Muster und sind NICHT angefasst** (Stop-Bedingung —
|
||||
gehört in eine eigene Runde, sinnvollerweise mit TP30):
|
||||
|
||||
```
|
||||
routeros/import-core-rsc.py Z. 50, 74
|
||||
routeros/apply-core-cutover-l3.py Z. 29, 55
|
||||
routeros/backup-core.py Z. 29, 41
|
||||
routeros/restore-core.py Z. 30, 42
|
||||
routeros/backup-ap1.py Z. 29, 41
|
||||
```
|
||||
|
||||
**Entwarnung zum Snapshot:** `/export` auf ROS 7.24 gibt WLAN-Passphrasen **gar nicht** aus
|
||||
(0 Vorkommen im Vollexport, live geprüft). Die Transaktionsakte im Git ist sauber.
|
||||
|
||||
## 🔧 Zweiter Nebenbefund: Worktrees können `gc-*.py` nicht ohne Handgriff ausführen
|
||||
|
||||
`docs/nas-vlan20/stacks/210-nautobot.yml` ist gitignored und existiert deshalb **nur im
|
||||
Haupt-Checkout**. In einem Worktree scheitern `gc-transaktion.py` und `gc-configplan.py` am
|
||||
Nautobot-Token. Behelf in dieser Session war ein Symlink auf den Haupt-Checkout — **der gehört nicht
|
||||
committet**. Dauerhafte Antwort wäre `NAUTOBOT_TOKEN` aus `~/.secrets/exports.zsh` (gc-configplan
|
||||
liest die Variable bereits; gc-transaktion liest nur die Stack-Datei).
|
||||
|
||||
## Unverändert offen (nicht Teil dieser Session)
|
||||
|
||||
1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — ⚠️ **die `ap-map` neu einfrieren**, s.o.
|
||||
2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt; fehlende `MCP_MIKROMCP_*_PASS` in `exports.zsh`)
|
||||
3. MikroMCP-Neustart (Registry inkl. ap3 wird nur beim Start gelesen)
|
||||
4. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste** statt Einzelwert, `tx-power` vorher messen)
|
||||
5. Versions-Angleichung 7.24 → 7.24.1
|
||||
@@ -108,11 +108,22 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
|
||||
- 🆕 **WLAN-Logging persistent seit 2026-08-30 (TP25 Fund E):** `wireless` + `caps` gehen vom Core
|
||||
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. **Fund E ist wieder offen**, Funk-Parameter werden bis zur Datengrundlage
|
||||
bewusst **nicht** angefasst.
|
||||
nicht diagnostizierbar.
|
||||
- 🔬 **TP25 Fund E — Hebel 1 läuft seit 2026-08-31 08:09 (LAUFENDER VERSUCH, nicht Endstand):**
|
||||
`sec-main` steht am Core auf **`ft=yes ft-over-ds=no`** (vorher `yes/yes`). Belegt am Manager an
|
||||
allen vier aktiven Master-VAPs (`cap-wifi3/4/5/6`). Transaktion
|
||||
**`TP25-fund-e-ft-over-ds`** ist **OFFEN** (Scope `wifi-security`, Ablauf **2026-09-03**),
|
||||
Geräte-Backup `pre-tp25-funde-ftoverds.backup` liegt auf dem Core.
|
||||
⇒ **Compliance steht deshalb bewusst auf 134/135** — der eine Drift ist genau dieser Versuch und
|
||||
wird von `gc-transaktion.py status` als *erwartet* ausgewiesen. **135/135 kommt beim COMMIT
|
||||
zurück**, nachdem 24 h gemessen sind und das Template nachgezogen ist; das Skript verweigert den
|
||||
Commit ohnehin, solange der Scope driftet. Baseline zum Vergleich: **93× `reauthenticating`**,
|
||||
93/93 vom iPhone `F2:62:4C:E1:AF:09`, 93/93 auf `dirtyvader-main`.
|
||||
- **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 5 Geräte in der Registry),
|
||||
**Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
|
||||
**135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30) — live gegen die API
|
||||
**135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30;
|
||||
**seit 2026-08-31 vorübergehend 134/135 — der eine Drift ist die offene Transaktion
|
||||
`TP25-fund-e-ft-over-ds`, s. oben, kein Fehler**) — live gegen die API
|
||||
geprüft am **2026-08-23**; zuletzt dazugekommen: **`wifi-access-list`** (08-22), **`queue`**
|
||||
(08-23, TP6) und **`ip-firewall-mangle`** (08-23, TP6.1), s. TP22-Nachtrag im Archiv).
|
||||
*(Hier stand bis zum 08-23 „100/100 bei 25 Rules" — eine Zählung, die TP6.1 am selben Tag überholt
|
||||
@@ -249,7 +260,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 erledigt) | 2026-08-24 |
|
||||
> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E offen, Hebel 1 `ft-over-ds=no` läuft, Messung bis 09-01** | 2026-08-31 |
|
||||
> | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
|
||||
> | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
|
||||
> | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
|
||||
@@ -1119,7 +1130,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 ▸ 🟢 **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 OFFEN, HEBEL 1 LÄUFT (2026-08-31 08:09): `ft-over-ds=no` auf `sec-main`, Messung bis 2026-09-01** · 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),
|
||||
@@ -1363,14 +1374,62 @@ der Flucht auf einen **25 dB schlechteren** AP (`-89 dBm`).
|
||||
Band-Steering, hier liegt ein **Authentifizierungs**problem vor. Details und Messrezept im
|
||||
[Handoff vom 2026-08-31](handoff-20260831-wlan-fund-e.md).
|
||||
|
||||
**🚫 Kein Funk-Parameter wird geändert, solange keine Daten da sind.** Drei Hebel, **einzeln** und je
|
||||
als Transaktion (`gc-transaktion.py`), in dieser Reihenfolge:
|
||||
**🚫 Kein Funk-Parameter wird geändert, solange keine Daten da sind.** Vier Hebel, **einzeln** und je
|
||||
als Transaktion (`gc-transaktion.py`). **Reihenfolge korrigiert am 2026-08-31** durch den Befund oben —
|
||||
die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressiert, während hier ein
|
||||
**Authentifizierungs**problem gemessen ist:
|
||||
|
||||
| # | Hebel | Begründung der Reihenfolge | Risiko |
|
||||
|---|---|---|---|
|
||||
| 1 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen** | sehr gering |
|
||||
| 2 | `ft-over-ds=no` auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten | gering |
|
||||
| 3 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch |
|
||||
| # | Hebel | Begründung der Reihenfolge | Risiko | Stand |
|
||||
|---|---|---|---|---|
|
||||
| 1 | **`ft-over-ds=no`** auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten. Kleinster Eingriff, der die verdächtige Achse trifft | gering | 🔬 **gezogen 2026-08-31 08:09**, Messung läuft |
|
||||
| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | 🔜 nur wenn (1) nicht greift |
|
||||
| 3 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen**. Adressiert die **Band-Oszillation** — ein anderes Symptom | sehr gering | 🔜 |
|
||||
| 4 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch | 🔜 |
|
||||
|
||||
#### 🔬 Hebel 1 — gezogen am 2026-08-31 08:09, Messung läuft bis 2026-09-01
|
||||
|
||||
**Was steht:** `sec-main` am Core auf **`ft=yes ft-over-ds=no`**. Abnahme **am Manager** über alle
|
||||
Master-VAPs — `cap-wifi3/4/5/6` (= ap2 + ap3) melden `ft=true ft-over-ds=false`; `cap-wifi1/2` (= ap1)
|
||||
sind leer, weil ap1 funkstill ist. Danach `remote-cap provision [find]`; alle drei CAPs kamen mit
|
||||
`state=Ok` zurück, alle VAPs `running=yes` **am CAP gelesen**, und das iPhone hing 71 s später wieder
|
||||
auf `dirtyvader-main` mit **`auth-type=ft-wpa3-psk`** und **frischer DHCP-Lease** `10.40.10.196` —
|
||||
also die vorgeschriebene Abnahme (Lease, nicht Registration-Table). 30 Clients insgesamt zurück.
|
||||
|
||||
**Governance:** Transaktion `TP25-fund-e-ft-over-ds` (Scope `wifi-security`, Ablauf 2026-09-03),
|
||||
Geräte-Backup `pre-tp25-funde-ftoverds.backup` auf dem Core, Snapshot
|
||||
[`docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc`](transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc).
|
||||
Compliance danach **134/135**, und der Diff ist **exakt** `ft-over-ds=yes → no` auf `sec-main` —
|
||||
kein Kollateral-Drift durch die Re-Provisionierung. Das GC-Template wird **beim Commit** nachgezogen,
|
||||
nicht vorher: sonst wäre der laufende Versuch unsichtbar und `status` könnte ihn nicht mehr von einem
|
||||
Versehen unterscheiden.
|
||||
|
||||
🔴 **Die `cap-wifiN`-Karte hat sich durch die Re-Provisionierung VERSCHOBEN** — wer die Logs vom
|
||||
31.08. auswertet, muss den Schnitt kennen, sonst ordnet er Ereignisse dem falschen AP zu:
|
||||
|
||||
| | vor 08:09 (Log 07:xx) | ab 08:09 |
|
||||
|---|---|---|
|
||||
| ap1 (funkstill) | — | `cap-wifi1` / `cap-wifi2` |
|
||||
| ap2 | `cap-wifi1` / `cap-wifi2` | `cap-wifi3` / `cap-wifi5` |
|
||||
| ap3 | `cap-wifi5` / `cap-wifi6` | `cap-wifi4` / `cap-wifi6` |
|
||||
|
||||
⚠️ **Korrektur am Befund: `main` unterscheidet sich in ZWEI Attributen, nicht einem.** Neben
|
||||
`ft=yes ft-over-ds=yes` fährt `sec-main` als einzige SSID **`authentication-types=wpa3-psk` allein**;
|
||||
die fünf anderen sind `wpa2-psk,wpa3-psk`. Die Kontrollgruppe trennt also FT **und** WPA3-only nicht
|
||||
voneinander. Das ändert nichts an der Hebelreihenfolge (die Foren-Hypothese nennt genau die
|
||||
Kombination WPA3+FT), aber die Formulierung „genau ein Attribut" ist zu stark — **wenn Hebel 1 und 2
|
||||
beide nichts bewegen, ist `wpa2-psk,wpa3-psk` auf `sec-main` der nächste Kandidat, nicht `signal-range`.**
|
||||
|
||||
**Messung (Erfolgskriterium): `reauthenticating` für `F2:62:4C:E1:AF:09` geht auf ~0, ohne dass die
|
||||
anderen SSIDs neue Ereignisse zeigen. Die Zahl MUSS sich bewegen.**
|
||||
|
||||
```bash
|
||||
ssh root@10.40.20.100 "pct exec 400 -- sh -c 'cat /opt/tp5-syslog/log/10.40.20.1/2026-0*-*.log |
|
||||
grep reauthenticating | grep -oE \"([0-9A-F]{2}:){5}[0-9A-F]{2}\" | sort | uniq -c'"
|
||||
```
|
||||
|
||||
Baseline **93** (alle iPhone, alle `main`); davon **79 am 31.08., alle in Stunde 07**, der letzte um
|
||||
**07:34:43** — also **vor** dem Eingriff. Zwischen 08:00 und 08:15 kein einziges. Das ist noch **kein
|
||||
Ergebnis**, nur der saubere Schnitt.
|
||||
|
||||
*(Der Defekt war nie gegenstandslos, nur unbelegt: Fund B/C wurden am 08-20 mit ap1 auf `ether15`
|
||||
gemessen — also in genau der Stellung, in der ap1 heute wieder hängt. Er ist platzierungsunabhängig.)*
|
||||
|
||||
14
docs/transaktionen/TP25-fund-e-ft-over-ds.json
Normal file
14
docs/transaktionen/TP25-fund-e-ft-over-ds.json
Normal file
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"change_id": "TP25-fund-e-ft-over-ds",
|
||||
"device": "crs326-core",
|
||||
"scope": "wifi-security",
|
||||
"match_config": [
|
||||
"/interface wifi security"
|
||||
],
|
||||
"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",
|
||||
"snapshot": "docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc",
|
||||
"device_backup": "pre-tp25-funde-ftoverds.backup"
|
||||
}
|
||||
11
docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc
Normal file
11
docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc
Normal file
@@ -0,0 +1,11 @@
|
||||
# Snapshot des Scopes 'wifi-security' auf crs326-core, 2026-08-31 (Transaktion TP25-fund-e-ft-over-ds)
|
||||
# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
|
||||
|
||||
/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
|
||||
Reference in New Issue
Block a user