# TP13 — „Botschafts-WLAN": Beacon-SSID als schwarzes Brett an die Nachbarschaft > **Stand 2026-08-19 · vorbereitet, nicht ausgeführt.** fun/low-prio, blockiert nichts. > **Umgesetzt wird nur die Beacon-Variante** — die Captive-Portal-Variante steht am Ende als Option > mit vorgelagertem Rechts-Gate, wird aber nicht geplant. --- ## 1. Idee Eine SSID, deren **Name die Botschaft ist** — z.B. `Kanal-11-bitte-freihalten`. Leitgedanke: wer die SSID sieht, ist nah genug, um zu stören; die Nachricht erreicht also genau die Zielgruppe. --- ## 2. 🔴 Der Denkfehler im ursprünglichen Entwurf Der TP-Text sagte bisher: *„reine Namens-SSIDs = Slave-VAPs mit eigener `configuration` (nur `ssid=`, **kein Security**/Datapath)"* — und begründete das damit, dass reine Namens-SSIDs **ohne offenen Zugang** rechtlich unkritisch seien. **Beides zusammen geht nicht.** Eine SSID ohne `security` **ist** ein offenes WLAN. Genau das, was der Rechtsvorbehalt (Impressumspflicht/Störerhaftung, User privat in AT) ausschließen will — Fremdgeräte könnten sich verbinden. **Richtig ist:** die Botschafts-SSID bekommt **WPA2/WPA3 mit einem PSK, den niemand kennt.** Sie beacont den Namen für jeden sichtbar, ist aber für niemanden beitretbar. Das ist der Unterschied zwischen „unkritisch" und „offenes WLAN" — und er kostet nichts. --- ## 3. Technik: es läuft über CAPsMAN, nicht mehr pro AP ⚠️ **Der Technik-Abschnitt des TP stammt aus der Standalone-Ära und ist seit TP28 (2026-08-17) ungültig.** Die APs sind reine CAPs; ihre lokale WLAN-Config ist auf die `cap`-Zeile eingedampft. `routeros/.secrets/ap{1,2}-prov-base.rsc` ist für den WLAN-Teil **Historie**. **Ist-Stand am Manager `crs326-core` (live gelesen 2026-08-19):** ``` /interface wifi configuration 9 Objekte (cfg-main-5g-ap1/ap2, cfg-main-2g-ap1/ap2, cfg-infra, cfg-iot, cfg-media, cfg-untrusted, cfg-guest) /interface wifi datapath 6 Objekte (dp-main, dp-infra, dp-iot, dp-media, dp-untrusted, dp-guest) -- alle bridge=bridge /interface wifi provisioning 4 Zeilen, eine je Radio (ap1/ap2 x 5GHz/2,4GHz) ``` Eine neue SSID entsteht damit in **einem** Deploy auf den Core statt in zweien auf die APs — für TP13 eine Vereinfachung gegenüber dem alten Entwurf. > 📌 `cfg-infra` existiert, steht aber in **keiner** `slave-configurations`-Liste — `dirtyvader-infra` > ist seit TP25 bewusst offline. Nicht als Fehler „reparieren". ### 3.1 🔴🔴 Die Datapath-Falle — der teuerste Punkt dieses Runbooks Auf den CAPs steht `slaves-datapath=dp-caps-slaves`: ein lokales Objekt mit `bridge=bridge` und **ohne** `vlan-id`. Der Manager schickt seinen Datapath mit, **der CAP übernimmt davon aber nur die `vlan-id`** (genau das war die Ursache des 14-Stunden-Ausfalls am 2026-08-18, s. TP28-Nachtrag). **Folge für eine Botschafts-SSID:** gibt man ihr am Manager **keinen** Datapath bzw. einen **ohne** `vlan-id`, landet der VAP in `bridge` — und zwar ungetaggt, also faktisch im alten VLAN1. Das ist exakt das Leck, das TP3.1 gekostet hat (`cfg-main-2g` ohne datapath). **Richtig:** ein eigener Datapath mit **explizitem, totem `vlan-id`** — eine VLAN-ID, die - in **keinem** DHCP-Server vorkommt, - in der Bridge-VLAN-Tabelle **nicht** auf den AP-Trunk-Ports getaggt ist, - und in keinem der sieben produktiven Netze liegt (10/20/30/40/50/90/99). Dann laufen Frames dieses VAP ins Leere — was genau der Zweck ist. Der PSK verhindert schon den Beitritt; der tote Datapath ist der zweite, unabhängige Riegel. **Beide setzen, nicht einen.** ### 3.2 VAP-Budget — geprüft, unkritisch Live von `ap1` (`/interface wifi radio print detail`): ``` max-interfaces=16 max-vlans=128 max-station-interfaces=3 hw-type=QCA6018 ``` Belegt sind aktuell **4** VAPs auf dem 5-GHz-Radio (`wifi1` + 3 Slaves) und **5** auf dem 2,4-GHz-Radio (`wifi2` + 4 Slaves). Es ist also reichlich Platz — **die Interface-Zahl ist nicht die Grenze.** ⚠️ **Die echte Grenze ist Airtime, nicht die Zahl.** Jeder zusätzliche VAP sendet eigene Beacons (~10×/s, auf 2,4 GHz mit niedriger Basisrate). Ein bis zwei Botschafts-SSIDs sind unproblematisch; eine Handvoll kostet spürbar Airtime in einem Band, das laut TP25 ohnehin das engere ist. → **Empfehlung: genau eine SSID, auf 2,4 GHz** (größere Reichweite = mehr Nachbarn sehen sie, und das 5-GHz-Band bleibt frei für Nutzverkehr). --- ## 4. Umsetzung (alles via Nautobot Golden Config) Der Governance-Entscheid gilt: **keine Direkt-Changes am Gerät.** Die Objekte gehören ins Template, nicht per MikroMCP an den Core. 1. **SSID-Name + Botschaft final festlegen.** ⚠️ Der Name ist öffentlich sichtbar und dauerhaft — keine Adresse, kein Nachname, nichts, was die Wohnung identifiziert. Er sollte eine *Bitte* transportieren, keine Beschwerde. 2. **Datapath** `dp-botschaft` mit `bridge=bridge` und totem `vlan-id` (§3.1). 3. **Security** mit WPA2/WPA3-PSK — Passphrase zufällig, **wird nirgends verteilt**. Ablage bei den übrigen WLAN-Secrets (`routeros/.secrets/wlan-psks.env`, gitignored). 4. **Configuration** `cfg-botschaft` (ssid, security, datapath) im Template [`nautobot/mikrotik_routeros.j2`](../nautobot/mikrotik_routeros.j2) — dort, wo die anderen `cfg-*`-Objekte stehen. 5. **Provisioning:** `cfg-botschaft` in die `slave-configurations` der beiden **2,4-GHz**-Zeilen aufnehmen (ap1 `D0:EA:11:4D:40:E6`, ap2 `D0:EA:11:4D:40:3F`). 6. **Deploy** über `nautobot/gc-configplan.py`, danach **Backup → Intended → Compliance**, damit die neue SSID sofort unter Drift-Kontrolle steht und nicht als Fremdkörper gilt. ⚠️ **Nicht während eines Calls deployen.** Änderungen an der Provisioning-Liste re-applien die Radios. *(Beim TP28-Cutover blieb das folgenlos, weil dynamische VAPs ihre Werte inline tragen — verlassen sollte man sich darauf nicht.)* --- ## 5. Abnahme 🔴 **Nicht die Registration-Table** — sie zeigte während des 14-Stunden-Ausfalls 25 zufriedene Clients. | Prüfung | Erwartung | |---|---| | Fremdgerät sieht die SSID im Scan | ja — das ist der Zweck | | Beitrittsversuch mit beliebigem Passwort | scheitert | | **Die sechs produktiven SSIDs ziehen frische DHCP-Leases** | ja — **je SSID einzeln prüfen** | | Compliance nach dem Lauf | wieder grün, neue Objekte im Soll | Der dritte Punkt ist der wichtige: er ist die Lehre aus dem 2026-08-18. Eine Änderung an der Provisioning-Liste fasst **alle** Slave-VAPs an, nicht nur den neuen. --- ## 6. Nicht geplant: die Captive-Portal-Variante Ein **offenes** WLAN mit Portal auf eine lokale Info-Seite (RouterOS-Hotspot, eigenes isoliertes VLAN, `walled-garden`) wäre die ausführlichere Botschaft — aber es ist ein anderer Sachverhalt: - **Rechts-Gate zuerst** (User privat, AT): offenes WLAN + Portal berührt Impressumspflicht und Störerhaftung, weil **Fremd-Datenverkehr** entsteht. Bei der Beacon-Variante entsteht keiner. - **Technisch teurer:** Hotspot-Dienst, eigenes VLAN, DHCP dafür, Firewall-Zeilen unter deny-by-default, Info-HTML irgendwo gehostet. → Bleibt dokumentierte Option. **Erst das Rechts-Gate beantworten, dann planen** — nicht umgekehrt.