diff --git a/.claude/skills/projektstatus/SKILL.md b/.claude/skills/projektstatus/SKILL.md deleted file mode 100644 index a8e9f5b..0000000 --- a/.claude/skills/projektstatus/SKILL.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -name: projektstatus -description: Rendert den BF-Netzwerk-Projektstatus als Baum (alle Teilprojekte mit Status + kritischem Pfad). Use when Christoph nach "Projektstatus", "Fortschritt", "Baum", "Stand", "Übersicht" der TPs fragt, oder einen aktuellen Statusbaum sehen will. ---- - -# BF-Netzwerk Projektstatus (Baumform) - -Ziel: einen **aktuellen, kompakten Statusbaum aller Teilprojekte (TP)** ausgeben — gruppiert -nach Themenblöcken, mit Status-Marker je TP und einer Zeile „kritischer Pfad" darunter. - -## Quelle (immer frisch lesen — NIE aus dem Gedächtnis) - -Kanonischer Stand = **`docs/teilprojekte.md`** (SSoT). Das ist die einzige Pflichtlektüre. -Bei Detailfragen ergänzend: `MEMORY.md`-Index im Memory-Ordner + einzelne `project_*`-Memories. - -**Ablauf:** -1. `docs/teilprojekte.md` komplett lesen (Datei ist groß → ggf. in 2 Reads: Zeilen 1–290, dann 291–Ende). -2. Status je TP aus den `▸ …`-Headern und ✅/⏳/🔜/⏸️-Markern ableiten — **nicht** aus diesem Skill - oder aus alten Memories raten; die Datei überschreibt alles. -3. Baum rendern (Format unten). Datum aus dem Kontext (`currentDate`) in die Überschrift. - -## Status-Marker (Legende) - -`✅` fertig · `⏳` WIP/teil-erledigt · `🔜` TODO/geplant · `⏸️` vertagt · `◄` Kern-Ziel - -## Themenblöcke (Gruppierung des Baums) - -Immer diese Reihenfolge — spiegelt Fundament → Ausbau → Ziel: - -1. **FUNDAMENT** — TP1, TP2, TP4 -2. **WLAN / CAPsMAN** — TP3, TP3.1, TP3.2, TP3.3 (+ Sonos-Migration unter TP3) -3. **DISCOVERY (mDNS/SSDP)** — TP7, TP7.1, TP7.2 -4. **IP-MIGRATION VLAN1→VLAN20** — TP14 (+ 14.1–14.5) + Omada-PVID-Fix -5. **SHELLY-MIGRATION** — TP17 -6. **CF-TUNNEL / EXTERNER ZUGANG** — TP16 -7. **FIREWALL / QoS** — TP5, TP5.1, TP6 (TP6 = Kern-Ziel ◄) -8. **HARDWARE** — TP15 -9. **VPN** — TP10 -10. **RESEARCH-GATED / SPÄTER** — TP8, TP9, TP11, TP12, TP13, TP-R - -## Ausgabeformat - -- ASCII-Baum in einem ```-Codeblock (├── │ └── ─). -- Je TP: ` TP ()`. -- Wichtige Unterpunkte/Caveats als eingerückte `└─`-Zeile (max. 1–2 je TP, nur das Entscheidende). -- Legende als letzte Zeile im Codeblock. -- Nach dem Codeblock **eine** Zeile **„Kritischer Pfad gerade:"** mit der aktuellen Arbeitskette - (aktuell: Omada-PVID-Fix + TP14.3-Sweep → TP14.5-Gate → TP5 Deny-by-default → TP6 CAKE/QoS; - TP17 + TP3.3 laufen unabhängig daneben) — diese Kette aber ebenfalls aus `teilprojekte.md` - §„Reihenfolge / Abhängigkeiten" verifizieren, nicht hart übernehmen. - -## Ergänzungen vor/nach dem Baum - -Christoph ergänzt oft Kontext **vor oder nach** dem Baum (z.B. „…und pack die offenen -Firewall-Punkte drüber" / „…mit Fokus auf TP17"). Solche Zusatzwünsche: -- **vor** dem Baum → als kurzer Vorspann (z.B. Highlight/Frage beantworten), dann Baum. -- **nach** dem Baum → als Nachtrag (Detailauszug, nächste Schritte, offene Entscheidungen). -Der Baum selbst bleibt im obigen Format stabil; die Ergänzungen rahmen ihn. diff --git a/docs/matter-pairing-infra-ssid-runbook.md b/docs/matter-pairing-infra-ssid-runbook.md new file mode 100644 index 0000000..5819de3 --- /dev/null +++ b/docs/matter-pairing-infra-ssid-runbook.md @@ -0,0 +1,94 @@ +# 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. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index ca7736f..2b77a91 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -605,6 +605,57 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated - Konzept für FM/BF/DW. → TP-R. +#### TP12.1 — IPv6 im LAN (ULA) + v6-Firewall ▸ 🟠 **KONKRET GEWORDEN (2026-08-22), Treiber: Matter/Thread** +> **Anlass:** der runde IKEA-Fühler **TIMMERFLOTTE** (Matter over Thread) ließ sich nicht anlernen — +> „pairing failed" in der Companion-App. Ursache ist **nicht** die Firewall, sondern dass zwischen +> VLAN10 und VLAN20 **überhaupt kein IPv6 geroutet wird**. Damit ist TP12 vom Konzept-TP zu einem +> Punkt mit einem konkreten, wiederkehrenden Schaden geworden. + +- **Befund am `crs326-core` (live gelesen 2026-08-22):** + - IPv6-Adressen: **ausschließlich Link-Local** (`fe80::…`) auf jedem Interface. Keine ULA, keine GUA. + - IPv6-Routing-Tabelle: nur `::1/128` und `fe80::/64` je Interface. **Keine Route** auf den + Thread-OMR-Prefix `fd92:505a:c64e:1::/64` und keine auf `fd03:cace:953f:e13d::/64` (den On-Link-Prefix, + den der OTBR auf VLAN20 wirbt). + - `/ipv6 nd`: Default-Eintrag, `advertise-dns=no` — es gibt aber ohnehin keine Prefixe zu werben. +- 🔴🔴 **Der eigentliche Kostenpunkt ist nicht IPv6, sondern die Firewall:** `/ipv6 firewall filter` ist + **komplett leer**. Heute harmlos, weil ohne Adressen nichts geroutet wird. In der Sekunde, in der + Adressen vergeben werden, steht **IOT→MAIN offen, GUEST→INFRA offen — an TP5 vorbei**. Das gesamte + TP5-Regelwerk muss **vorher** in v6 nachgebaut sein, sonst reißt dieser TP genau die Segmentierung + auf, die TP5 am 2026-08-18 geschlossen hat. **Das ist die Arbeit, nicht die Adressvergabe.** +- 🔎 **Warum Matter das braucht:** Commissioning läuft in zwei Etappen. Etappe 1 (BLE zum Gerät) ist + netzunabhängig. In Etappe 2 muss der Commissioner — das iPhone — das Gerät auf dem **operativen + Thread-Netz** wiederfinden (DNS-SD `_matter._tcp`, dann CASE). Dafür braucht das Telefon eine + IPv6-Route in den OMR-Prefix hinein. iPhone hängt auf VLAN10, OTBR auf VLAN20 → Etappe 2 bricht ab. + Die ~30 bereits laufenden Matter-Knoten widersprechen dem nicht: HA und OTBR sitzen auf **demselben + Host** (`wpan0` ist lokal), im Betrieb quert nichts die VLAN-Grenze. Nur das *Anlernen* tut es. +- ⚠️ **Zwei Fallen, die den naiven Weg verbauen:** + - **(a) Der OMR-Prefix ist generiert und wandert.** Am 2026-08-22 um 17:33 (OTBR-Neustart) sind alle + Knoten von `fd92:505a:c64e:1::/64` auf **Mesh-Local** `fd66:986:170:bb1a::/64` gefallen — und + Mesh-Local ist per Definition *nicht* off-mesh routbar. Eine statische Route auf den OMR-Prefix ist + also nur so stabil wie der nächste Neustart. Ihn im Thread-Dataset festzunageln formiert das Netz + neu — mit 30+ produktiven Knoten daran kein Nebenbei-Change. + - **(b) RouterOS lernt fremde RAs nicht.** Der OTBR wirbt den OMR-Prefix per RA mit Route-Information-Option + auf VLAN20. Der Core müsste die annehmen — als forwardender Router für dieses Interface tut er das + nicht sauber. +- 📡 **Dritter Baustein: DNS-SD über die VLAN-Grenze.** `mdns-repeat-ifaces` am Core (vlan10/20/30/40/90) + ist **IPv4**. Für Matter-Discovery bräuchte es zusätzlich einen v6-fähigen Reflector — der + `mcast-relay`-LXC (108) kann das prinzipiell, aber als **zweite Instanz** mit Beinen in VLAN10+VLAN20 + (SSDP-Instanz ist VLAN10+VLAN40, s. Gotcha in CLAUDE.md). +- ✅ **Der Workaround, der das umgeht statt löst:** iPhone zum Anlernen auf **VLAN20** — dann sind Telefon + und Border Router auf demselben L2-Link, der OTBR wirbt dort On-Link-Prefix *und* Route, und iOS wertet + beides aus. `cfg-infra` / SSID `dirtyvader-infra` (`dp-infra`, VLAN20, `sec-infra` mit PSK) existiert am + Manager **bereits**, ist nur in **keiner** `provisioning`-Zeile als Slave hinterlegt. Runbook: + [`docs/matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md). +- ✅ **Der Weg, der das Problem dauerhaft erledigt:** Matter-Server-Option **`ble_proxy: true`** (ab HA + 2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist + raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind + reine Advertisement-Scanner (kein GATT), ein **ESP32 als ESPHome-BT-Proxy** (`active: true`) reicht. + Der **ESPHome Device Builder ist bereits installiert**. Damit wird TP12.1 für Matter **optional**. +- **Abh.:** hängt an nichts. **Blockiert nichts** — außer künftige Thread-Geräte, solange weder + `ble_proxy` noch die `-infra`-SSID steht. Reihenfolge innerhalb des TP ist zwingend: + **v6-Firewall nachbauen → dann erst Adressen vergeben.** Gehört unter TP12 (Gesamtkonzept 3 Standorte), + ist aber allein für BF ausführbar. + ### TP13 — „Botschafts-WLANs" ▸ 🔜 **AUSFÜHRBAR (Runbook 2026-08-19)** — `docs/tp13-botschafts-wlan-runbook.md` · fun/low-prio > 📌 Am 2026-08-19 überarbeitet: der Technikteil beschrieb noch Standalone-APs (SSIDs entstehen seit > TP28 am **Manager**, also ein Deploy statt zwei), und der Entwurf „nur `ssid=`, kein Security" war ein @@ -1259,6 +1310,32 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". > die erste Stelle im Haus, an der **Fund E (`signal-range`-Boden) wirklich hilft**, weil es hier eine > bessere Alternative gibt. **Test steht aus** (Handover §5). Korrektur zur Terrasse: der Platz, an dem > das Telefon normalerweise steht, ist mit **−46…−66 dBm gut**; schlecht ist der Teil dahinter. +> **(G) 2026-08-22 — Sideboard-Test BEENDET, ap1 geht zurück auf `core ether15`.** Ergebnis nach einem +> Tag, User-Befund: **ap1 am Sideboard richtet das Wohnzimmer nicht** — womit die RF-Vorhersage aus der +> Idee von 2026-08-13 (geschlossenes Media-Möbel, Metallgehäuse, niedrig) bestätigt ist — **und der +> Preis ist ein dunkles Schlafzimmer** (Fund F: −61 → −83 dBm). Damit ist die Idee **„ap1 ersetzt den +> Sideboard-Switch" entschieden: nein.** Die User-Vorgabe „Platzierung hat Vorrang vor dem eingesparten +> Gerät" greift — und die bessere Platzierung ist die alte. Transaktion +> `TEST-ether3-trunk-ap1-sideboard` wird zurückgerollt (`ether3` wieder **untagged VLAN40** = +> Sideboard-Access-Port); Compliance geht damit auf 92/92 zurück. +> 🔴 **Reihenfolge beim Rückbau:** erst ap1 physisch auf `ether15` umstecken, **dann** die Config +> zurückrollen. Umgekehrt hängt ap1 im Moment des Deploys ungetaggt in MEDIA und verliert vlan99/Manager. +> `ether15` ist durchgehend in allen VLANs getaggt geblieben, das Umstecken allein genügt also. +> ↗️ **Stattdessen als Nächstes:** ap2 wurde auf **2,5 m Höhe** gehievt (User 2026-08-22) — der billigste +> verbliebene Hebel unter der Randbedingung „kein neuer AP, solange nicht alles aus den vorhandenen +> rausgeholt ist". Wirkung **noch ungemessen**: Raumkarte mit [`tp25-walk-messung.sh`](tp25-walk-messung.sh) +> neu laufen, sonst steht Höhengewinn gegen Fund F ohne Zahlen im Raum. **Erster Eindruck des Users +> (2026-08-22): die Terrasse ist damit besser ausgeleuchtet** — subjektiv, Nachmessung steht aus und +> ist genau der Punkt, an dem der Dead Spot aus (E)/(F) zu prüfen wäre. +> ⚠️ **Korrektur 2026-08-22 (User):** die Formulierung „der Steering-Fall entfällt mit dem Rollback" war +> **falsch**. Was entfällt, ist nur die *konkrete Ausprägung* aus (F) — Schlaf-/Kinderzimmer bei 2 m zu +> ap1 an ap2 klebend. **Der Defekt selbst bleibt**, er verlagert sich nur: Übergabe bzw. Abriss passieren +> dann an anderen Stellen im Haus. Das ist auch belegt: **Fund B** (Sticky Client, dreimal an ap1 bei +> −43 dBm vorbei, eine einzige Übergabe) und **Fund C** (Band-Ping-Pong, 12 Wechsel in 9 min) wurden am +> **2026-08-20 gemessen — mit ap1 auf `ether15`**, also in genau der Stellung, in die wir jetzt +> zurückgebaut haben. Der Sticky-Client-Defekt ist damit **platzierungsunabhängig**. +> ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach +> dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos. > 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).** > ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`, Scope > `bridge-vlan`, Frist 2026-09-04) — die Compliance ist deshalb **absichtlich** nicht 92/92. diff --git a/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.json b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.json index 7e14baf..37f293b 100644 --- a/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.json +++ b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.json @@ -8,7 +8,8 @@ "reason": "ap1 testweise am Sideboard, Uplink auf core ether3 statt ether15 (TP25 Standorttest)", "started": "2026-08-21", "expires": "2026-09-04", - "state": "open", + "state": "rolledback", "snapshot": "docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.snapshot.rsc", - "device_backup": "vor-ether3-trunk-20260821.backup" + "device_backup": "vor-ether3-trunk-20260821.backup", + "closed": "2026-08-22" } diff --git a/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback-deployed.rsc b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback-deployed.rsc new file mode 100644 index 0000000..ae08796 --- /dev/null +++ b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback-deployed.rsc @@ -0,0 +1,15 @@ +# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 55ff3f32-3bc6-4c16-9ddb-613e335474df, Status Completed, +# am Geraet gegengeprueft). Beleg fuer den Rueckbau von TEST-ether3-trunk-ap1-sideboard. +# Abgeleitet aus dem Snapshot vom 2026-08-21, aber angepasst: +# - `add` -> `set [find ... and !dynamic]` (der Generator-Vorschlag haette neu angelegt) +# - Backslash-Fortsetzungen aufgeloest (Netmiko bricht daran) +# - VLAN 1 und 100 ausgelassen: ether3 kommt dort nicht vor +# Hinweis: `gc-transaktion.py rollback` ueberschreibt die .rollback.rsc bei jedem Aufruf neu — +# deshalb liegt der Beleg hier unter eigenem Namen. +/interface bridge vlan set [find where vlan-ids=10 and !dynamic] tagged=ether1,ether8,ether13,ether15 +/interface bridge vlan set [find where vlan-ids=20 and !dynamic] tagged=ether8,ether13,ether15 +/interface bridge vlan set [find where vlan-ids=30 and !dynamic] tagged=ether1,ether8,ether15 +/interface bridge vlan set [find where vlan-ids=40 and !dynamic] tagged=ether1,ether8,ether13,ether15 untagged=ether2,ether3,ether4,ether5 +/interface bridge vlan set [find where vlan-ids=50 and !dynamic] tagged=ether1,ether8,ether15 +/interface bridge vlan set [find where vlan-ids=90 and !dynamic] tagged=ether1,ether8,ether15 +/interface bridge vlan set [find where vlan-ids=99 and !dynamic] tagged=ether8,ether15,bridge diff --git a/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback.rsc b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback.rsc new file mode 100644 index 0000000..f335844 --- /dev/null +++ b/docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback.rsc @@ -0,0 +1,16 @@ +# Rueckbau-VORSCHLAG fuer TEST-ether3-trunk-ap1-sideboard (crs326-core, Scope bridge-vlan) +# Aus dem Snapshot vom 2026-08-21. NICHT ungeprueft deployen: +# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird, +# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen. + +/interface bridge vlan +add bridge=bridge untagged=ether1,ether2 vlan-ids=1 +add bridge=bridge tagged=ether1,ether8,ether13,ether15 vlan-ids=10 +add bridge=bridge tagged=ether8,ether13,ether15 vlan-ids=20 +add bridge=bridge tagged=ether1,ether8,ether15 untagged=ether14 vlan-ids=30 +add bridge=bridge tagged=ether1,ether8,ether13,ether15 untagged=\ +ether2,ether3,ether4,ether5 vlan-ids=40 +add bridge=bridge tagged=ether1,ether8,ether15 vlan-ids=50 +add bridge=bridge tagged=ether1,ether8,ether15 vlan-ids=90 +add bridge=bridge tagged=ether8,ether15,bridge vlan-ids=99 +add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100 diff --git a/docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc b/docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc new file mode 100644 index 0000000..4a68ae4 --- /dev/null +++ b/docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc @@ -0,0 +1,2 @@ +/interface wifi provisioning set [find where comment="ap1 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest,cfg-infra +/interface wifi provisioning set [find where comment="ap1 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest,cfg-infra diff --git a/docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc b/docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc new file mode 100644 index 0000000..a179bed --- /dev/null +++ b/docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc @@ -0,0 +1,2 @@ +/interface wifi provisioning set [find where comment="ap1 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest +/interface wifi provisioning set [find where comment="ap1 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest