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.

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.
Datapath dp-botschaft mit bridge=bridge und totem vlan-id (§3.1).
Security mit WPA2/WPA3-PSK — Passphrase zufällig, wird nirgends verteilt. Ablage bei den übrigen WLAN-Secrets (routeros/.secrets/wlan-psks.env, gitignored).
Configuration cfg-botschaft (ssid, security, datapath) im Template nautobot/mikrotik_routeros.j2 — dort, wo die anderen cfg-*-Objekte stehen.
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).
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.

7.1 KiB Raw Blame History Unescape Escape