# 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.