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