Christoph Emsenhuber
6c2297ad95
TEST-ether3-trunk-ap1-sideboard ist zurueckgerollt und geschlossen: ether3 faellt aus allen tagged-Listen und ist in VLAN40 wieder untagged (Sideboard- Access-Port). Am Geraet gegengeprueft, Snapshot-Diff leer. crs326-core ist damit transaktionsfrei. TP25 Fund (G): ap1 am Sideboard richtet das Wohnzimmer nicht und kostet das Schlafzimmer (-61 -> -83 dBm). Die Idee "ap1 ersetzt den Sideboard-Switch" ist damit entschieden -- nein, Platzierung vor eingespartem Geraet. ap2 haengt jetzt auf 2,5 m, Terrasse subjektiv besser, Nachmessung steht aus. Korrektur im selben Zug: die erste Fassung von (G) behauptete, der Steering- Fall entfalle mit dem Rollback. Falsch -- es entfaellt nur die konkrete Auspraegung. Fund B und C wurden am 08-20 mit ap1 auf ether15 gemessen, also in genau der Stellung, in die wir zurueckgebaut haben; der Defekt ist platzierungsunabhaengig und verlagert sich nur. Fund E bleibt die Massnahme und ist jetzt oberster offener Punkt. TP12.1 neu (unter TP12, kein Duplikat daneben): Matter/Thread-Commissioning scheitert an fehlendem IPv6-Routing zwischen VLAN10 und VLAN20 -- nicht an der Firewall. Der Kostenpunkt des TP ist aber nicht die Adressvergabe, sondern dass /ipv6 firewall filter leer ist: heute harmlos, ab der ersten Adresse ein Loch an TP5 vorbei. Reihenfolge deshalb zwingend v6-Firewall vor Adressen. Runbook + Kommandodateien fuer die temporaere dirtyvader-infra-SSID (cfg-infra existiert bereits, haengt nur in keiner provisioning-Zeile). Vorbereitet, nicht deployt. Repo-lokalen projektstatus-Skill geloescht: er war seit 11. Juli stale (harte Themenblöcke, kritischer Pfad von TP14.3) und wurde nicht geladen -- aktiv ist der globale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
95 lines
4.5 KiB
Markdown
95 lines
4.5 KiB
Markdown
# Runbook — `dirtyvader-infra` temporär ausstrahlen (Matter/Thread-Pairing)
|
|
|
|
**Zweck:** ein iPhone für die Dauer eines Matter-Commissionings auf **VLAN20** bringen, damit Telefon und
|
|
OpenThread-Border-Router auf **demselben L2-Link** sitzen. Dann wirbt der OTBR dem Telefon On-Link-Prefix
|
|
*und* Route in den Thread-OMR-Prefix per RA, iOS wertet beides aus — und die fehlende IPv6-Route zwischen
|
|
VLAN10 und VLAN20 (**TP12.1**) wird gar nicht erst berührt.
|
|
|
|
**Status:** 🟠 vorbereitet 2026-08-22, **nicht deployt** — s. Blocker.
|
|
|
|
> **Erst prüfen, ob dieses Runbook überhaupt nötig ist.** Seit 2026-08-22 läuft der Matter-Server mit
|
|
> `ble_proxy: true` (`BLE is enabled (proxy mode)`). Wenn HA eine **connectable** BLE-Quelle hat,
|
|
> kommissioniert HA selbst und das Telefon wird nicht gebraucht. Shelly-BLE-Proxies sind
|
|
> **Advertisement-Scanner ohne GATT** und reichen dafür vermutlich nicht; ein ESP32 als
|
|
> ESPHome-BT-Proxy (`active: true`) reicht. **Dieses Runbook ist der Plan B.**
|
|
|
|
---
|
|
|
|
## 🔴 Blocker: eine offene Transaktion je Gerät
|
|
|
|
Auf `crs326-core` ist **`TEST-ether3-trunk-ap1-sideboard`** offen (Scope `bridge-vlan`, Frist 2026-09-04,
|
|
TP25-Standorttest). `gc-transaktion.py begin` verweigert deshalb eine zweite Akte auf demselben Gerät
|
|
(Regel 3). Vor dem Deploy also **eines von beiden**:
|
|
|
|
- die ether3-Akte `commit`en oder `rollback`en — sie gehört TP25, das ist Christophs Entscheidung; **oder**
|
|
- bewusst ohne Transaktion deployen — dann ist es **undokumentierter Drift**, genau das, was
|
|
`docs/transaktionen/README.md` abschaffen wollte. Nicht empfohlen.
|
|
|
|
## Vorbedingungen (alle live geprüft 2026-08-22 ✅)
|
|
|
|
| | |
|
|
|---|---|
|
|
| `cfg-infra` existiert am Manager | ✅ SSID `dirtyvader-infra`, `datapath=dp-infra` mit **explizitem `vlan-id=20`** |
|
|
| `sec-infra` hat einen PSK | ✅ 13 Zeichen gesetzt — **kein offenes Netz**. Passphrase steht am Core (`/interface/wifi/security`), nicht in diesem Repo |
|
|
| `slaves-datapath` auf ap1 | ✅ `dp-caps-slaves` (`bridge=bridge`, **ohne** `vlan-id`) |
|
|
| `cfg-infra` in einer `provisioning`-Zeile | ❌ **in keiner** — genau das ist der Change |
|
|
|
|
⚠️ Die ersten drei sind zusammen die Falle, die am 2026-08-18 **14 Stunden** gekostet hat: fehlt
|
|
`slaves-datapath`, assoziieren Clients auf Slave-VAPs sauber und bekommen **nie** DHCP. Hier ist sie
|
|
entschärft — deshalb steht sie in der Tabelle und nicht im Kleingedruckten.
|
|
|
|
## Deploy
|
|
|
|
Scope für die Transaktion ist **`wifi-provisioning`** (keine `bridge-vlan`!).
|
|
|
|
```bash
|
|
python3 nautobot/gc-transaktion.py begin --device crs326-core \
|
|
--scope wifi-provisioning --change-id TEST-infra-ssid-matter-pairing \
|
|
--expires 2026-08-29 \
|
|
--reason "dirtyvader-infra temporaer auf ap1, iPhone fuer Matter-Commissioning auf VLAN20 (TP12.1)"
|
|
```
|
|
|
|
```bash
|
|
python3 nautobot/gc-manual-plan.py --device crs326-core \
|
|
--commands-file docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc \
|
|
--change-id TEST-infra-ssid-matter-pairing --dry-run
|
|
```
|
|
|
|
Erst nach gelesenem Dry-Run dasselbe mit `--deploy` statt `--dry-run`.
|
|
|
|
Ändert `cfg-infra` auf **ap1** (beide Bänder). ap2 bleibt bewusst außen vor: kleinerer Blast-Radius, und
|
|
zum Anlernen steht man ohnehin an einem Ort. Reicht die Abdeckung nicht, dieselben zwei Zeilen für
|
|
`ap2 5GHz` / `ap2 2.4GHz` ergänzen.
|
|
|
|
Erscheint der VAP nicht, hat der CAP nicht re-provisioniert — dann am Manager
|
|
`/interface/wifi/capsman/remote-cap/provision [find]` nachziehen.
|
|
|
|
## Abnahme
|
|
|
|
**Eine frische DHCP-Lease aus `dhcp-v20` vom iPhone.** *Nicht* die Registration-Table — die zeigte während
|
|
des 14-Stunden-Ausfalls 25 zufriedene Clients, die kein DHCP hatten.
|
|
|
|
```bash
|
|
# am Core
|
|
/ip dhcp-server lease print where server=dhcp-v20
|
|
```
|
|
|
|
## Rückbau — **nicht vergessen**
|
|
|
|
Ein WLAN nach INFRA ist nichts, was stehen bleiben soll. Nach erfolgreichem Pairing:
|
|
|
|
```bash
|
|
python3 nautobot/gc-manual-plan.py --device crs326-core \
|
|
--commands-file docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc \
|
|
--change-id TEST-infra-ssid-matter-pairing-rollback --deploy
|
|
python3 nautobot/gc-transaktion.py rollback --change-id TEST-infra-ssid-matter-pairing
|
|
```
|
|
|
|
Danach `gc-transaktion.py status` — die Akte muss geschlossen und `wifi-provisioning` wieder driftfrei sein.
|
|
|
|
## Siehe auch
|
|
|
|
- **TP12.1** in [`teilprojekte.md`](teilprojekte.md) — warum es ohne VLAN20-SSID nicht geht, und was der
|
|
saubere Weg wäre (v6-Firewall zuerst, dann Adressen).
|
|
- [`transaktionen/README.md`](transaktionen/README.md) — die drei Regeln des Transaktions-Werkzeugs.
|