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!).

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)"

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.

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

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 — warum es ohne VLAN20-SSID nicht geht, und was der saubere Weg wäre (v6-Firewall zuerst, dann Adressen).
transaktionen/README.md — die drei Regeln des Transaktions-Werkzeugs.

4.8 KiB Raw Blame History

Runbook — dirtyvader-infra temporär ausstrahlen (Matter/Thread-Pairing)