Files

Christoph Emsenhuber 777ac95c3f TP13: Technikteil war seit TP28 falsch, plus ein Denkfehler

Zwei Sachen standen in TP13, die so nicht stimmen.

Erstens beschrieb der Technikteil noch Standalone-APs und wollte die
Beacon-SSIDs in ap{1,2}-prov-base.rsc ergaenzen. Seit dem CAPsMAN-Cutover
entstehen SSIDs am Manager auf dem Core -- was fuer TP13 sogar einfacher
ist, ein Deploy statt zwei.

Zweitens der eigentliche Fund: der Entwurf wollte "nur ssid=, kein
Security" und begruendete das damit, dass Namens-SSIDs ohne offenen Zugang
rechtlich unkritisch seien. Eine SSID ohne Security IST aber ein offenes
WLAN, also genau der Fall, den der Rechtsvorbehalt ausschliessen will.
Richtig ist ein PSK, den niemand kennt: beacont den Namen, niemand kommt
rein. Kostet nichts.

Dazu die Datapath-Falle: ein Slave-VAP ohne explizite vlan-id am Manager
landet ungetaggt in der Bridge, weil der CAP vom Manager-Datapath nur die
vlan-id uebernimmt. Gleiche Mechanik wie der 14-h-Ausfall. Die
Botschafts-SSID braucht deshalb beides -- PSK und toten Datapath.

VAP-Budget am Geraet nachgesehen statt geschaetzt: max-interfaces=16 je
Radio, belegt sind 4 bzw. 5. Die Zahl ist also nicht die Grenze, Airtime
ist es -- jeder VAP beacont eigenstaendig. Empfehlung steht im Runbook.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-19 16:00:15 +02:00

7.1 KiB

Raw Blame History

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