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>
7 lines
617 B
Plaintext
7 lines
617 B
Plaintext
# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 1469f0f7-fc52-47e1-bd65-a83ac709d89c, Completed).
|
|
# Danach ZWINGEND: /interface wifi capsman remote-cap provision [find where identity="ap2"]
|
|
# Ohne die Re-Provisionierung bleiben die VAPs am CAP bestehen und senden weiter.
|
|
# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
|
|
/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
|
|
/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
|