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>
4.5 KiB
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
commiten oderrollbacken — sie gehört TP25, das ist Christophs Entscheidung; oder - bewusst ohne Transaktion deployen — dann ist es undokumentierter Drift, genau das, was
docs/transaktionen/README.mdabschaffen 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!).
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.