98 lines
4.8 KiB
Markdown
98 lines
4.8 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:** ✅ **einmal durchgespielt am 2026-08-22** (TIMMERFLOTTE angelernt, danach zurückgebaut).
|
|
Dies ist ab jetzt **der Standardweg** für jedes neue Thread-Gerät, nicht der Plan B.
|
|
|
|
> **Warum es keinen bequemeren Weg gibt.** Der Matter-Server läuft seit 2026-08-22 mit
|
|
> `ble_proxy: true` (`BLE is enabled (proxy mode)`, Handshake steht). Damit könnte **HA selbst**
|
|
> kommissionieren und das Telefon wäre raus — es fehlt nur eine **connectable** BLE-Quelle.
|
|
> Die Shellys sind es nicht: gemessen `slots: 0, free: 0` auf allen dreien, also reine
|
|
> Advertisement-Scanner ohne GATT. Ein ESP32 als ESPHome-BT-Proxy wäre die Lösung, ist aber per
|
|
> **User-Entscheid 2026-08-22 abgelehnt**. Bleibt dieses Runbook — oder TP12.1 wirklich bauen.
|
|
|
|
> ✅ **Was seit dem ersten Durchlauf leichter ist:** `cfg-infra`, `dp-infra` und `sec-infra` bleiben
|
|
> auf User-Wunsch dauerhaft am Manager stehen (inaktiv, in keiner `provisioning`-Zeile). Der Change
|
|
> ist deshalb wirklich nur noch das Hinzufügen von `cfg-infra` zu zwei Slave-Listen.
|
|
|
|
---
|
|
|
|
## ~~🔴 Blocker: eine offene Transaktion je Gerät~~ — erledigt 2026-08-22
|
|
|
|
Die ether3-Akte wurde am 2026-08-22 zurückgerollt, `crs326-core` ist transaktionsfrei — der Blocker
|
|
besteht nicht mehr. **Er kann jederzeit wiederkommen:** Regel 3 erlaubt genau *eine* offene Akte je
|
|
Gerät. Steht beim nächsten Mal etwas anderes auf `crs326-core` offen, muss das erst geschlossen werden.
|
|
`gc-transaktion.py status` sagt es in einer Zeile.
|
|
|
|
## 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.
|