Der Workaround aus TP12.1 ist durchgespielt: dirtyvader-infra temporaer auf
ap2, iPhone auf VLAN20, TIMMERFLOTTE per Companion-App angelernt (25,44 C /
53,1 % rF / Batterie 100 %, Technik UG). SSID danach wieder vom Funk;
cfg-infra/dp-infra/sec-infra bleiben auf User-Wunsch inaktiv am Manager
stehen, damit das naechste Thread-Geraet ein Zweizeiler ist. Beide Akten
geschlossen, crs326-core transaktionsfrei.
TP12.1 bleibt offen: der Workaround umgeht das fehlende IPv6-Routing, er
behebt es nicht.
Neuer Gotcha in CLAUDE.md, an dem ich mich heute selbst verrannt habe:
slave-configurations zu setzen bewirkt am Funk nichts ohne
remote-cap provision -- und zwar in BEIDE Richtungen, auch beim Entfernen.
Schlimmer: beim Rueckbau wird der Interface-Kommentar geleert, waehrend der
VAP weitersendet. Ich habe auf comment~"dirtyvader-infra" geprueft, nichts
gefunden und "weg" gemeldet -- tatsaechlich liefen wifi13/wifi18 mit vlan=20
weiter. Richtige Abnahme ist datapath.vlan-id am CAP. Also wieder: Wirkung
messen, nicht Anzeige.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TEST-infra-ssid-matter-pairing (Scope wifi-provisioning, Frist 2026-08-29):
cfg-infra als Slave-VAP in beide ap2-Provisioning-Zeilen. Nicht ap1, weil der
gerade auf ether11 (VLAN10-Access) haengt und kein CAP ist.
Zweck ist TP12.1: das iPhone fuer EIN Matter-Commissioning auf denselben
L2-Link wie der OTBR bringen, damit dessen RA (On-Link-Prefix + Route in den
Thread-OMR-Prefix) beim Telefon ankommt. Danach zurueckbauen -- ein WLAN nach
INFRA soll nicht stehen bleiben.
Zwei Dinge fuer die Ablage:
- Provisioning-Zeilen aendern reicht nicht, der CAP muss re-provisioniert
werden (/interface wifi capsman remote-cap provision). Das ist eine Aktion,
keine Config, also kein Nautobot-Weg noetig.
- Danach zeigt der MANAGER running=false fuer alle cap-*-Interfaces, waehrend
am CAP wifi13/wifi18 sauber DBR laufen. Beim Interface-Zustand ist der CAP
die Wahrheit, nicht der Manager -- Gegenstueck zur bekannten Regel, dass die
Registration-Table am Manager zu lesen ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
