UniFi Event-WLAN — Komplettes Setup¶
Mobiles Wettkampf-WLAN für Dreifachsporthallen. Lokales Wertungssystem (Tablets → Server via Socket.IO), JSON-Upload an Online-Ergebnisdienst über Dual-WAN (Kabel + LTE-Failover). Kampfrichter-Tablets vom Internet isoliert.
Kapitel 0 — Schnellaufbau für den Wettkampf¶
Diese Seite reicht, um die Anlage aufzubauen und zu betreiben. Alles ist vorkonfiguriert. Im UniFi-Controller / in der App nichts ändern — kein WLAN, keine Passwörter, keine Kanäle, keine Einstellungen. Nur Kabel und Strom.
1) Aufstellen & verkabeln (Kabel sind beschriftet):
- APs auf die Stative, an die Tischenden, leicht in die Halle gewinkelt
- RUT901 (LTE-Box): ZUERST die Antennen festschrauben — ERST DANN Strom!
(Strom ohne Antenne kann den Sender beschädigen.) SIM steckt bereits.
- Verkabeln nach diesem Schema:
Hallen-Internetkabel (falls vorhanden) → CGU "WAN" (2,5G-Port)
RUT901 (LAN) → CGU "LAN4"
CGU "LAN1" → USW Port 8
USW Port 1 → AP 1 (PoE, kein Netzteil nötig)
USW Port 2 → AP 2 (PoE, kein Netzteil nötig)
USW Port 7 → Server-Box (Notebook ODER Odroid)
Hallen-Kabel ist optional — ohne läuft alles über die LTE-Box (RUT901). APs brauchen KEIN eigenes Netzteil, der Strom kommt übers Netzwerkkabel (PoE).
2) Einschalten — in dieser Reihenfolge:
- 1. RUT901 (Antennen dran!) — kurz warten, bis die Signal-LEDs leuchten
- 2. CGU (das weiße Hauptgerät mit LED-Frontfeld)
- 3. USW (der Switch — die APs starten automatisch mit)
- 4. Server-Box zuletzt einschalten
→ Ist sowohl Notebook als auch Odroid dabei: das NOTEBOOK ist der
Server (zuerst an), der Odroid läuft als Reserve automatisch mit.
→ Ist nur eine Box da: einfach die anschließen.
3) Läuft alles? (ohne Computer, nur hinschauen + ein Tablet):
- CGU + Switch: LEDs leuchten ruhig (nicht dauerhaft am Blinken)
- APs: Lichtring leuchtet ruhig weiß/blau (nicht aus, nicht dauerblinkend)
- Ein Kampfrichter-Tablet mit WLAN "DTLWLAN_Unifi5G" verbinden
Passwort: Kidx4wdil.
→ ACHTUNG: der Punkt am ENDE gehört zum Passwort! (9 Zeichen + Punkt = 10)
- Wertungs-Webseite öffnet sich / verbindet → FERTIG. Mehr braucht es nicht.
Tablet zeigt „Verbunden, kein Internet"? Das ist NORMAL und richtig — das Wertungsnetz hat absichtlich kein Internet. Einfach ignorieren.
WLAN-Namen zum Verbinden:
DTLWLAN_Unifi5G → Kampfrichter / Wertungs-Tablets
DTLTEAM_Unifi5G → Wettkampfleitung
DTLVIDEO_Unifi5G → Video / Replay
→ alle drei haben DASSELBE Passwort: Kidx4wdil. (Punkt am Ende gehört dazu!)
Wenn ein Tablet zickt (das darf der Helfer selbst tun):
- WLAN am Tablet "vergessen" und neu verbinden (löst die meisten Probleme)
- In den WLAN-Einstellungen "Privates DNS" auf AUS stellen
- Tablet näher an einen AP / kurz aus- und einschalten
- Hilft nichts: anderes Tablet probieren, sonst anrufen
Finger weg von (sonst geht das Setup kaputt):
- UniFi-App / Controller-Einstellungen ändern (WLAN, Passwörter, Kanäle, VLANs)
- Die LTE-Box (RUT901) umkonfigurieren
- Zusätzliche WLANs ein-/ausschalten (z.B. solche mit …AP1 / …AP2 am Ende)
- Die Server-Box neu einrichten oder Kabel umstecken, „um es zu verbessern"
Abbau: Geräte ausschalten/Strom trennen → Kabel beschriftet aufrollen → APs vorsichtig von den Adaptern lösen → Stative einklappen. RUT-Antennen erst nach dem Stromtrennen abschrauben.
Alles ab Kapitel 1 ist Hintergrund/Konfiguration und für den reinen Aufbau NICHT nötig. Wer nur auf- und abbaut, kommt mit dieser Seite aus.
1. Hardware¶
| Komponente | Rolle |
|---|---|
| Cloud Gateway Ultra (CGU) | Router, UniFi-Controller, Dual-WAN |
| USW-Lite-8-POE | Switch, PoE+ für APs |
| 2× U6 Mesh | Access Points (4×4 auf 5 GHz) |
| Teltonika RUT901 (Dual-SIM) + O2-Multicard + 1NCE | LTE-Uplink mit Auto-Failover |
| Server / ServerNotebook | Wertungs-Backend (Node.js) |
| Walimex-Stative + 3D-Adapter | AP-Montage |
2. Netzwerk-Topologie¶
Kabel-Internet ─── CGU WAN (2,5 GbE) → primär
RUT901 (LTE) ─── CGU LAN4 = WAN2 → Failover
│
│
CGU (Routing + Controller)
│
USW-Lite-8-POE
├─ U6 Mesh AP1 (PoE+)
├─ U6 Mesh AP2 (PoE+)
└─ Server / ServerNotebook
│
WLAN (5 GHz):
├─ SSID "Kampfrichter" → VLAN 10 (KEIN Internet)
├─ SSID "Wettkampfleitung" → VLAN 20
└─ SSID "Videobeweis" → VLAN 30 (lokal)
3. IP-/VLAN-Plan¶
| VLAN | Name | Subnetz | DHCP-Pool | Internet | Zweck |
|---|---|---|---|---|---|
| 1 | Hauptnetz | 10.254.1.0/24 | .50–.99 | JA | Server/ServerNotebook + Infra |
| 10 | Kampfrichter | 10.254.10.0/24 | .50–.199 | NEIN | Wertungs-Tablets der Kampfrichter |
| 20 | Wettkampfleitung | 10.254.20.0/24 | .50–.149 | NEIN | Leitungs-Geräte, Admin |
| 30 | Videobeweis | 10.254.30.0/24 | .50–.200 | NEIN (lokal) | Video-Replay/-Beweis-Geräte |
| 40 | Intern+Internet | 10.254.40.0/24 | .50–.99 | JA | Vertrauens-Notebook: Internet UND Server/VLAN 1 |
| 50 | Internet-Gast | 10.254.50.0/24 | .50–.99 | JA (nur Internet) | Echter Gast: nur raus, KEIN Server-/LAN-Zugriff |
Schema: drittes Oktett = VLAN-ID (10.254.
.x) — übersichtlich. Drei Internet-Stufen auseinanderhalten:
- VLAN 1 = Infrastruktur + Server (Internet + alles)
- VLAN 40 = Internet + Server, aber kein Event-VLAN (dein Arbeits-Notebook)
- VLAN 50 = nur Internet, sonst nichts (fremder Gast)
Event-VLANs (10/20/30) sind das Gegenstück: Server JA, Internet NEIN.
Statische Reservierungen in VLAN 1 / Hauptnetz (10.254.1.x):
| IP | Gerät |
|---|---|
| .1 | Cloud Gateway Ultra |
| .2 | Aktiver Node.js-Wertungs-Server. Primär das Windows-Notebook; ist keins auf .2, übernimmt der Odroid die .2 (Auto-Switch-Script). Läuft das Notebook, geht der Odroid auf .3 = Reserve/Backup. Es ist IMMER genau eine Box auf .2. |
| .3 | Odroid im Reserve-Modus (nur belegt, wenn das Notebook die .2 hält) |
| .3 | USW-Lite-8-POE |
| .10 | U6 Mesh AP1 |
| .11 | U6 Mesh AP2 |
Server/ServerNotebook in VLAN 1 (mit Internet) — nur ER lädt JSON hoch. Kampfrichter-Tablets in VLAN 10 (ohne Internet) erreichen den Server per Inter-VLAN-Routing (in UniFi standardmäßig erlaubt), kommen aber nie ins Internet. Videobeweis: Handys (VLAN 30) laden Clips zum Server hoch (Store-and-Forward, kein Live-Stream), die Wettkampfleitung (VLAN 20) schaut sie vom Server an. Beide Wege laufen über den Server (VLAN 1), kein Internet.
10.254.1.2 ist „der aktive Server": Auto-Switch auf dem Odroid prüft beim Boot, ob .2 schon belegt ist (= Notebook läuft) — wenn ja, Odroid nimmt .3 (Reserve); wenn nein, übernimmt der Odroid die .2 und wird selbst der Node-Server. So ist .2 immer der aktive Server, egal welche Hardware. DNS- Override (204-Trick, § 9b), Tablet-Adressierung (:3002) und der Ansible-Port- Forward (§ 9c) zeigen darum fest auf .2.
⚠️ Zweck & Grenze: Das ist Redundanz gegen defekte Server-Hardware, KEIN Live-Failover. Welche Box der Server ist, steht nach Transport/Aufbau fest (vor dem Wettkampf) — ab dann wird nicht mehr gewechselt. Auto-Switch greift nur beim Boot, kein Datensync. Geht eine Box beim Aufbau nicht, nimmt man die andere: Notebook defekt → Odroid bootet auf die freie .2; Odroid defekt → Notebook hält .2. NICHT abgedeckt: Hardware-Tod MITTEN im laufenden Wettkampf — ohne Sync keine verlustfreie Übernahme (akzeptiertes Restrisiko; als billige Versicherung ggf. regelmäßiger Daten-Export auf die andere Box / USB). Der 204-Responder muss auf der aktiven .2-Box laufen (Odroid: nginx ✓; Notebook: captivePortal.js — testen, sobald das Notebook die .2 ist). Hinweis: nur der Odroid hat den Ausweich-Check. Soll das Notebook Backup sein, bleibt es im Backup-Fall einfach AUS (es nimmt .2 statisch, ohne Prüfung) — nicht parallel ans Netz, sonst IP-Konflikt.
4. Phase 1 — Erstinbetriebnahme (zu Hause)¶
- CGU ans Stromnetz, WAN an dein Heim-Internet (FritzBox o.ä.)
- USW-Lite an CGU LAN1 (USW-Port 8 = Uplink/Trunk, non-PoE)
- AP1 + AP2 auf PoE+-Ports des USW (Port 1 + 2)
- Server an USW (Port 7), Wettkampf-PC an USW (Port 6)
- UniFi-App / unifi.ui.com → CGU einrichten, Account, Cloud-Backup an
- APs erscheinen → "Adopt"
- Firmware-Updates für ALLE Geräte einspielen
- Default-Netz auf 10.254.1.x umstellen:
Settings → Networks → "Default" → Host Address / Gateway IP:
10.254.1.1 / Subnet /24
→ DHCP-Pool passt sich an (10.254.1.50–.99 einstellen)
→ ACHTUNG: alle Geräte (auch dein Laptop) holen sich danach neue
Leases im 10.254.1.x-Bereich; Controller dann unter 10.254.1.1
oder weiter über unifi.ui.com erreichbar
- Statische IPs gemäß Tabelle oben vergeben (Client → Settings → Fixed IP)
5. Phase 2 — Netzwerke / VLANs anlegen¶
Settings → Networks → Create New
- VLAN 10 "Kampfrichter": 10.254.10.1/24, DHCP .50–.199
- VLAN 20 "Wettkampfleitung": 10.254.20.1/24, DHCP .50–.149
- VLAN 30 "Videobeweis": 10.254.30.1/24, DHCP .50–.200
- VLAN 40 "Intern+Internet": 10.254.40.1/24, DHCP .50–.99
→ normales Netz (KEIN Guest-Typ!). Internet + Server-Zugriff
regelt die Firewall-Zone unten (§ 9).
- VLAN 50 "Internet-Gast": 10.254.50.1/24, DHCP .50–.99
→ Netzwerktyp "Guest" wählen (isoliert automatisch von allen
anderen VLANs, lässt nur Internet zu — genau das Gewünschte).
Falls der Guest-Typ ein Captive Portal erzwingt: normales Netz
nehmen und stattdessen über die Firewall-Zone unten abriegeln.
VLAN 1 (Default) bleibt das Hauptnetz (Server/ServerNotebook + Infrastruktur).
Lease-Zeit — wichtig fürs stabile Socket-Netz: Bei den großen Pools (150 Adressen) und Geräten, die während des Events verbunden bleiben, eine normale bis lange Lease wählen (z.B. 8–24 h, deckt den Eventtag). KEINE kurze Lease — sie ist unnötig und erzeugt nur DHCP-Chatter.
DHCP-Renewal wechselt die IP NICHT: der Client fragt nach der halben Lease-Zeit "darf ich behalten?", der Server (kennt die MAC) sagt ja → IP bleibt, Socket bleibt offen. Eine IP wechselt nur bei vollständigem Ablauf während Offline-Zeit + Neuvergabe — beim großen Pool praktisch ausgeschlossen. Socket-Stabilität hängt an stabiler AP-Verbindung + Socket.IO-Reconnect, nicht an der Lease-Zeit. (Hinweis: 802.11r AUS — siehe Funk-Abschnitt.)
6. Phase 3 — Dual-WAN Failover¶
Settings → Internet
- WAN1 (Port "WAN", 2,5 GbE):
- Quelle: Kabel-Internet der Halle
- Priorität: 1 (primär)
- Typ: DHCP (meist) oder PPPoE je nach Anschluss
- LAN4 als WAN2 umwidmen:
- Settings → Internet → "+ Add WAN" / Port LAN4 die WAN-Rolle geben
- Quelle: RUT901 (Ethernet von dessen LAN-Port)
- Priorität: 2 (Failover)
- Typ: DHCP
- Modus: "Failover" (NICHT Load Balancing)
- Optional SLA: Verification-Server z.B. 1.1.1.1 + 8.8.8.8, Timeout 3 s
Verhalten: CGU nutzt Kabel (WAN1) wenn vorhanden, schaltet automatisch auf LTE (WAN2) wenn Kabel ausfällt. Solange Kabel läuft, wird die 1NCE-SIM nicht angefasst.
Bei Hallen OHNE Kabel: WAN1 ist einfach offline, CGU nutzt automatisch WAN2 (LTE). Kein Eingriff nötig.
Port-Belegung CGU danach:
| Port | Speed | Belegung |
|---|---|---|
| WAN | 2,5 GbE | Kabel-Internet (Halle) |
| LAN1 | 1 GbE | → USW-Lite (Trunk, alle VLANs) |
| LAN2 | 1 GbE | frei (Reserve) |
| LAN3 | 1 GbE | frei (Reserve) |
| LAN4 (=WAN2) | 1 GbE | RUT901 LTE |
Alle LAN-Ports sind 1 GbE (identisch) — LAN1 ist Konvention, LAN2/3 gingen auch. LAN4 ist für WAN2 reserviert. Der Uplink LAN1 muss ein Trunk sein (Port Profile "All" — UniFi-Default), damit alle VLANs zum Switch/zu den APs durchkommen.
Alle Endgeräte hängen am USW-Lite (der CGU hat keinen PoE-Ausgang, die APs müssen also ohnehin an den Switch). PoE+ = Ports 1–4, normal = Ports 5–8.
| USW-Port | Belegung |
|---|---|
| 1 (PoE+) | U6 Mesh AP1 |
| 2 (PoE+) | U6 Mesh AP2 |
| 3 (PoE+) | frei (Reserve für 3. AP) |
| 4 (PoE+) | Internet-Gast-Port (Port-VLAN 50) — bei Bedarf, PoE bleibt ungenutzt |
| 5 | Intern+Internet-Port (Port-VLAN 40) — Vertrauens-Notebook |
| 6 | Wettkampfleitungs-PC (Port-VLAN 20) |
| 7 | Server / ServerNotebook (Port-VLAN 1) |
| 8 | → CGU LAN1 (Uplink/Trunk, alle VLANs) |
Uplink auf dem Nicht-PoE-Port 8 ist ideal: alle vier PoE-Ports (1–4) bleiben für APs frei, inkl. Reserve für einen 3. AP. APs auf PoE-Ports, alles andere auf 5–8. Kabelgebundene Geräte bekommen ihr VLAN über das Switch-Port-Profil: Server-Port → "Hauptnetz/VLAN 1", Wettkampfleitungs-PC-Port → "VLAN 20", Intern+Internet-Port → "VLAN 40", Internet-Gast-Port → "VLAN 50". Der Uplink-Port 8 bleibt Trunk ("All").
⚠️ Auch die Internet-Ports (VLAN 40 + 50) sind ENDGERÄT-Ports, KEINE Trunks: Native = ihr VLAN (40 bzw. 50), Tagged = Block All. NICHT Native VLAN 1 / Allow All — das wäre die Trunk-Config und steckt das Notebook ins falsche VLAN. Der Internet-/Server-Zugriff kommt aus der Firewall-Zone (§ 9), nicht aus dem Port-Trunk. Trunk (Native 1, Allow All) NUR für die AP-Ports + Uplink 8.
In neueren UniFi-Versionen heißt das "Native VLAN" + "Tagged VLAN Management":
- Endgerät (Server, PC): Native = sein VLAN, Tagged VLAN Management = Block All
- Trunk (AP-Ports 1/2, Uplink 8): Native = VLAN 1 (ServerNetz), Tagged VLAN Management = Allow All
- WICHTIG: AP-Ports NIE "Block All" — sonst kommen VLAN 10/20/30 nicht an den APs an und nur das Hauptnetz funktioniert.
⚠️ HÄUFIGER FEHLER (kostet Stunden!): AP-Port-Native NICHT auf VLAN 10 setzen, nur weil es der "Kampfrichter-AP" ist! Der AP bedient ALLE VLANs und braucht einen Trunk: Native = VLAN 1 (Management), alle SSID-VLANs getaggt. Steht der Native fälschlich auf VLAN 10, assoziieren sich Geräte zwar (Funk geht), bekommen aber KEINE IP ("rufe IP ab" hängt) — an JEDEM Gerät, egal welches. Symptom sieht aus wie ein Geräteproblem, ist aber der Port-Trunk.
Verkabelungs-Übersicht:
Kabel-Internet ─── CGU WAN (2,5G)
RUT901 (LTE) ─── CGU LAN4 (=WAN2)
CGU LAN1 ──(Trunk)─── USW Port 8 (non-PoE)
├─ Port 1 (PoE) → U6 Mesh AP1
├─ Port 2 (PoE) → U6 Mesh AP2
├─ Port 7 → Server/ServerNotebook (VLAN 1)
├─ Port 6 → Wettkampfleitungs-PC (VLAN 20)
├─ Port 5 → Intern+Internet-Notebook (VLAN 40)
└─ Port 4 (PoE) → Internet-Gast-Notebook (VLAN 50)
(PoE+ = Ports 1–4; Port 3 als Reserve für 3. AP frei. Port 4 liefert zwar PoE, ein Notebook ignoriert das — bei 3.-AP-Bedarf VLAN 50 auf einen 5–8er-Port legen.)
7. Phase 4 — SSIDs¶
Das sind die SSIDs für Profil A (Normal-Event) — eine je VLAN, gemeinsam auf beiden APs, mit Roaming. Für Profil B (Großevent) kommen pro-AP getrennte SSIDs dazu — siehe Phase 5, "Profil B — SSID-Trennung pro AP".
Settings → WiFi → Create New
SSID 1 — DTLWLAN_Unifi5G (Kampfrichter / Wertungs-Tablets)
- Name: DTLWLAN_Unifi5G
- Passwort: Kidx4wdil. (der Punkt am Ende gehört zum Passwort!)
- Network/VLAN: VLAN 10 (Kampfrichter)
- Band: NUR 5 GHz (2,4 GHz Haken raus)
- Bandwidth-Limit: keines (Traffic ist winzig)
- WPA2/WPA3 (WPA3 ok — war NICHT das Tab-M10-Problem, das war 802.11r, s. Phase 5)
SSID 2 — DTLTEAM_Unifi5G (Wettkampfleitung)
- Name: DTLTEAM_Unifi5G
- Passwort: Kidx4wdil. (gleiches wie alle — Punkt gehört dazu!)
- Network/VLAN: VLAN 20 (Wettkampfleitung)
- Band: NUR 5 GHz
- WPA2/WPA3
- Bandwidth-Limit: keines
SSID 3 — DTLVIDEO_Unifi5G (Videobeweis / Video-/Replay-Geräte)
- Name: DTLVIDEO_Unifi5G
- Passwort: Kidx4wdil. (gleiches wie alle — Punkt gehört dazu!)
- Network/VLAN: VLAN 30 (Videobeweis)
- Band: NUR 5 GHz
- WPA2/WPA3
- Bandwidth-Limit: via WiFi Speed Limit (s.u.)
Profil-B-SSIDs (Großevent, normalerweise PAUSIERT/ausgegraut): DTLWLAN_Unifi5GAP1 (Gruppe AP1) und DTLWLAN_Unifi5GAP2 (Gruppe AP2), beide VLAN 10. Bei diesen 802.11r ebenfalls AUS — sonst gleiches Tab-M10-Problem. Pausierte SSIDs zählen nicht zum aktiven Funkbetrieb (kein Beacon-Overhead).
WiFi Speed Limit für Videobeweis — OPTIONAL (in neueren Versionen; früher
"User Group"). Da nie mehrere Videos gleichzeitig laufen (max. 1 Upload +
1 Abruf), ist das Limit eigentlich unnötig — einzelne Clips dürfen ruhig mit
voller Geschwindigkeit übertragen. Nur bei wider Erwarten auftretenden
Engpässen nachrüsten:
Settings → Profiles → WiFi Speed Limit → Create New WiFi Speed Limit
- Name: Videobeweis-Limit
- Download/Upload: großzügig (z.B. 50 Mbps) — nur zum Kappen von Spitzen
- in der SSID "Videobeweis" unter Advanced → "WiFi Speed Limit" zuweisen
Empfehlung: erstmal WEGLASSEN. Da Video Store-and-Forward ohne gleichzeitige Streams ist, gibt es nichts abzusichern. Lässt sich beim ersten Event in 2 Minuten nachrüsten, falls nötig.
8. Phase 5 — Funk-Optimierung (kritisch!)¶
Zwei Betriebsprofile — gleiche Funk-Basis, unterschiedliche Leistung + SSID-Strategie. Du wählst je nach Event:
| Profil A — Normal-Event | Profil B — Großevent | |
|---|---|---|
| SSID-Strategie | eine SSID je VLAN (gemeinsam auf beiden APs) | pro AP eigene SSID (feste Zuordnung) |
| Sendeleistung | Medium | High / Maximum |
| Roaming | Standard (802.11r AUS — sonst koppeln Budget-Geräte nicht) | keins — Geräte kleben am AP |
| Verbinden | automatisch, egal welcher AP | manuell auf nächsten AP achten |
| Auto-Failover bei AP-Ausfall | ja | nein |
| Aufwand | minimal, alles automatisch | manuelle Gerätezuordnung |
| Wann | Standard, normale Events | viele Geräte, max. Kapazität/Kontrolle |
Standard = Profil A. Einfach verbinden, alles läuft automatisch, AP-Ausfall wird durch Roaming abgefangen. Profil B nur bei Großevents, wenn du Roaming komplett ausschließen und volle Leistung pro Zelle willst — um den Preis manueller Zuordnung und ohne Auto-Failover.
Gemeinsame Funk-Basis (BEIDE Profile)¶
Pro AP unter Devices → AP → Settings → Radios:
- 2,4 GHz: KOMPLETT DEAKTIVIEREN
(Blackview-Tablets dort schwach; spart Airtime + Interferenz)
- 5 GHz:
- Kanalbreite: 80 MHz (NICHT 160 — 160 kostet Empfindlichkeit)
(bei DFS-Problemen/maximaler Robustheit alternativ 40 MHz)
- AP1 Kanal: 36 (oder 40)
- AP2 Kanal: 100 (oder 104, DFS) — maximale Kanaltrennung
- Minimum RSSI: AUS (für beide Profile — s.u.)
Sendeleistung — je nach Profil¶
- Profil A (Normal): Medium (beide APs gleich, manuell/nicht Auto)
- Profil B (Großevent): High/Max (beide APs gleich, manuell/nicht Auto)
Warum bei Profil A nur Medium? Volle Leistung + Roaming = Uplink-Imbalance (AP brüllt, Tablet flüstert) + Sticky Clients + Zell-Überlappung → latenz- schädlich. Medium = saubere Zellen + besseres Roaming. Warum bei Profil B volle Leistung ok? Ohne Roaming entfällt der Sticky-Nachteil — die Geräte SOLLEN am AP kleben. Regel: jedes Gerät dem NÄCHSTEN AP zuweisen, dann ist auch der Uplink stark. Bei Funklöchern (Profil A): hoch auf High ODER 3. AP dazu.
Minimum RSSI — pro AP, NICHT bei der SSID (Devices → AP → Settings):
- Sitzt in den AP-Geräte-Settings (Seitenpanel), separat je 5G-Radio,
pro AP einzeln zu setzen
- EMPFEHLUNG: für den ersten Event AUS lassen
→ Risiko Kick-Loop: kickt ein AP einen Client in einer toten Ecke und
kein besserer AP ist über der Schwelle erreichbar, wird er endlos
erneut gekickt = Instabilität (Ubiquiti warnt selbst davor)
- NUR aktivieren (dann -75, beide APs), wenn der Coverage-Test zeigt, dass
überall ein zweiter AP über -75 dBm erreichbar ist, UND wenn Sticky
Clients tatsächlich auftreten
Dein Latenz-Problem (Power-Save) löst DTIM 1, nicht Min RSSI. Min RSSI ist reines Roaming-Feintuning mit echtem Eigentor-Risiko — im Zweifel weglassen.
Pro SSID unter Settings → WiFi → (SSID) → Advanced (ggf. "Manual"):
- DTIM Period: 1 → minimale Latenz für Socket-Verbindungen
- Disabled Data Rates: alles < 12 Mbit/s aus (alte 802.11b/g-Raten)
- Band Steering: nicht nötig (2,4 GHz ist aus)
- Fast Roaming (802.11r): AUS → siehe Warnung unten!
- BSS Transition (802.11v) / RRM (802.11k): optional, im Zweifel AUS
⚠️ 802.11r (Fast Roaming) AUS lassen! Budget-Android-Geräte (Lenovo Tab M10 u.a.) können sich mit aktivem 802.11r oft NICHT assoziieren — Symptom: WLAN zeigt "nicht in Reichweite" trotz vollem Signal. Da die Kampfrichter an FESTEN Positionen sitzen, braucht es Fast Roaming ohnehin nicht. WPA2/WPA3 ist dagegen unkritisch und kann anbleiben. (Verschlüsselung war NICHT das Problem — es war 802.11r.)
Profil B — SSID-Trennung pro AP (NUR Großevent)¶
Zusätzlich zu Profil A. Eliminiert Roaming komplett: jeder AP eigene SSID, Geräte fest zugewiesen. Volle Leistung (s.o.).
1) AP Groups anlegen (Settings → Profiles → AP Groups):
- "Gruppe-AP1" = nur AP1
- "Gruppe-AP2" = nur AP2
2) Pro VLAN zwei SSIDs (statt einer), je AP-Group zugewiesen:
- "Kampfrichter-A" → VLAN 10, AP Group "Gruppe-AP1"
- "Kampfrichter-B" → VLAN 10, AP Group "Gruppe-AP2"
(Wettkampfleitung/Videobeweis bei Bedarf ebenso splitten, sonst als
einzelne Roaming-SSID lassen — spart Beacon-Overhead)
3) Geräte beim Verbinden dem NÄCHSTGELEGENEN AP zuweisen:
- Geräte der Hallenhälfte AP1 → "...-A"
- Geräte der Hallenhälfte AP2 → "...-B"
→ wichtig für starken Uplink (Tablet-Sender ist schwach)
Zwischen Profil A und B umschalten — zwei zuverlässige Wege:
- Backup/Restore (empfohlen): zwei Controller-Backups vorhalten, "Profil-A-Normal" und "Profil-B-Großevent" (Phase 8). Umschalten per Restore — schaltet SSIDs UND Sendeleistung gleichzeitig, nichts wird vergessen, unabhängig von UI-Eigenheiten.
- Profil-B-SSIDs nur bei Bedarf: da Großevents selten sind, die per-AP- SSIDs (Kampfrichter-A/-B) erst zum Großevent anlegen, danach löschen. Normalbetrieb bleibt schlank (nur die 3 gemeinsamen SSIDs).
(Zum schnellen SSID-Wechsel: in der neuen UniFi-Version "Pause" je SSID — pausierte SSIDs senden keine Beacons, Config bleibt erhalten, ein Klick zurück. Sitzt in der WiFi-Liste. Backup/Restore bleibt der "nichts-vergessen"- Weg, weil es auch die Sendeleistung Medium↔High mitschaltet.)
9. Phase 6 — Firewall: Geräte vom Internet trennen¶
Das ist Pflicht — sonst ziehen die Kampfrichter-Tablets Updates (2 GB/Event gemessen!). Nur Server/ServerNotebook (VLAN 1) braucht Internet.
NICHT "Network Isolation" verwenden! Der Schalter in den Netzwerk-Settings blockt INTER-VLAN-Traffic (VLAN↔VLAN), nicht das Internet. Damit könnten die Tablets den Server nicht mehr erreichen — genau falsch herum.
Methode A — Zone-Based Firewall (UniFi Network 9.x, "Zones"/"Policy Table")¶
Policies arbeiten zwischen ZONEN, nicht einzelnen VLANs. Also die zu blockenden VLANs zuerst in eine eigene Zone packen:
1) Zone anlegen (Settings → Zones → Create Zone):
- Name: "Event-Lokal"
- Netzwerke: VLAN 10 + 20 + 30 zuweisen
- VLAN 1 NICHT — bleibt in Standard-Zone "Internal" (behält Internet)
2) Policies (Settings → Zones → Create Policy):
Policy 1: Source "Event-Lokal" → Destination "External/Internet" → BLOCK
Policy 2: Source "Event-Lokal" → Destination "Internal" → ALLOW
(Auto Allow Return Traffic AN — Server kann antworten/Video liefern)
Policy 3: Source "Event-Lokal" → Destination "Gateway" → ALLOW
(ZWINGEND für DHCP + DNS! Ohne diese Policy bekommen die
Geräte keine IP, weil der DHCP-Server am Gateway hängt.)
Policy 2 ist nötig, damit die Tablets den Server erreichen. Policy 3 ist ebenso zwingend — DHCP/DNS laufen über die "Gateway"-Zone, nicht über "Internal". Fehlt sie, kriegt kein Gerät in VLAN 10/20/30 eine IP. VLAN 1 behält Internet über die eingebaute "Internal → External"-Policy.
VLAN 40 „Intern+Internet" — Internet UND Server: wie VLAN 1, nur in eigenem Subnetz (damit das Notebook nicht im selben L2-Segment wie die Infrastruktur hängt). Eigene Zone, gezielte ALLOWs:
1) Zone anlegen: Name "Intern-Internet", Netzwerk: VLAN 40
2) Policies:
Intern-Internet → External → ALLOW (Internet)
Intern-Internet → Gateway → ALLOW (DHCP/DNS)
Intern-Internet → Internal → ALLOW (Server/VLAN 1 erreichbar)
Intern-Internet → Event-Lokal → BLOCK (braucht es nicht — sauberer)
Abkürzung: VLAN 40 einfach der Standard-Zone "Internal" zuweisen (wie VLAN 1) — dann hat es automatisch Internet + Server. Eigene Zone ist nur sauberer, wenn du Event-Lokal gezielt aussperren willst.
VLAN 50 „Internet-Gast" — nur Internet, kein Server: das Spiegelbild — INS Internet, aber NICHT zum Server oder zu den Event-VLANs. Wenn du das Netz NICHT als "Guest"-Typ angelegt hast (der isoliert schon von selbst), eigene Zone:
1) Zone anlegen: Name "Internet-Gast", Netzwerk: VLAN 50
2) Policies:
Internet-Gast → External → ALLOW (Internet — der ganze Zweck)
Internet-Gast → Gateway → ALLOW (DHCP/DNS, sonst keine IP)
Internet-Gast → Internal → BLOCK (kein Zugriff auf Server/VLAN 1!)
Internet-Gast → Event-Lokal → BLOCK (kein Zugriff auf VLAN 10/20/30)
Die beiden BLOCK-Policies sind der Punkt: ohne sie würde UniFi VLAN 50 per Standard-Inter-VLAN-Routing zum Server durchlassen. Hier ist Isolation ausnahmsweise GEWOLLT — anders als bei den Event-VLANs, die den Server ja brauchen. Deshalb ist für VLAN 50 der "Guest"-Netzwerktyp (oder "Network Isolation" an) genau richtig, während er für VLAN 10/20/30 verboten ist.
Merke den Unterschied: VLAN 40 → Internal = ALLOW, VLAN 50 → Internal = BLOCK. Das ist die einzige Zeile, die „Vertrauens-Notebook" von „Gast" trennt.
Methode B — Traffic Rules (ältere/parallele Oberfläche, falls vorhanden)¶
Settings → Security → Traffic Rules → Create — pro VLAN eine Regel:
Einfacher, kein Zonen-Gebastel. Block "Internet" lässt Inter-VLAN (Server) unberührt.
VLAN 40 + 50 hier NICHT ins Internet blocken (sollen ja raus). VLAN 40 braucht gar keine Regel — darf Internet UND Server. Nur VLAN 50 abriegeln: Block · Source VLAN 50 · Target = lokale Netze (VLAN 1/10/20/30), damit der Gast den Server nicht erreicht. Oder schlicht "Network Isolation" am VLAN 50 aktivieren.
Effekt (beide Methoden): Kampfrichter-, Wettkampfleitungs- und Videobeweis- Geräte erreichen weiterhin den Server (lokal, Inter-VLAN), aber nie das Internet — egal ob WAN gerade Kabel oder LTE ist. Nur das Hauptnetz (VLAN 1) lädt hoch.
Test:
- Tablet (VLAN 10) → google.com → muss FEHLSCHLAGEN
- Tablet (VLAN 10) → Server 10.254.1.2 → muss FUNKTIONIEREN
Tablets temporär Internet geben (z.B. für Updates zu Hause)¶
Variante 1 (empfohlen, kein UniFi-Eingriff):
- Tablets fürs Update mit dem Heim-WLAN (FritzBox) verbinden,
fürs Event zurück auf "DTLWLAN_Unifi5G"
→ nichts umzustellen, nichts rückgängig zu machen, kein Vergessen-Risiko
Variante 2 (Tablets bleiben auf Kampfrichter-SSID):
- Block-Policy "Event-Lokal → External" deaktivieren/Pause (alle Event-VLANs)
- Test: Tablet → google.com
- Falls trotzdem kein Internet (ZBF-Default sperrt custom Zone):
stattdessen Settings → Networks → Kampfrichter → Zone temporär "Internal"
ACHTUNG bei Variante 2: VOR dem nächsten Event den Block wieder aktivieren bzw. Zone zurück auf "Event-Lokal"! Sonst ziehen die Tablets am Event ihre Updates und fressen das LTE-Datenvolumen. Variante 1 (Heim-WLAN) hat dieses Risiko nicht.
9b. Connectivity-Check / "kein Internet"-Verhalten zähmen (204-Trick)¶
Das Event-Netz hat bewusst kein Internet. Android/iOS prüfen nach dem Verbinden gegen feste URLs ("Connectivity Check") und melden sonst "kein Internet" — mit zwei realen Risiken:
Gerät MIT SIM (Handys A35, Videobeweis): wechselt evtl. automatisch auf Mobilfunk
Jedes Gerät: springt evtl. auf ein offenes Hallen-WLAN (das hat ja Internet)
→ in beiden Fällen: Verbindung zum lokalen Wertungs-Server WEG
Minimal (für dedizierte Tablets):
- Auf den Wertungs-Tablets ALLE fremden WLANs vergessen (Hallen-, Heim-WLAN)
→ nur DTLWLAN_Unifi5G gespeichert lassen → nichts, wohin gewechselt werden kann
- Auf Geräten MIT SIM: "Automatisch zu mobilen Daten wechseln" / "Adaptive
Konnektivität" AUS (Samsung: WLAN → ⋮ → Erweitert)
- Auto-Connect zu öffentlichen Netzen AUS
Robust (für ALLE Geräte — dem Netz "Internet vorhanden" vorgaukeln):
- Lokale DNS-Einträge im Gateway, Check-Domains auf den Server zeigen:
Settings → Routing → DNS → Create Entry (Type: Host (A)):
connectivitycheck.gstatic.com → 10.254.1.2 (aktive Server-Box)
connectivitycheck.android.com → 10.254.1.2
www.msftconnecttest.com → 10.254.1.2 (Windows)
captive.apple.com → 10.254.1.2 (Apple)
Wichtig: Server-Box ist abwechselnd Windows ODER Odroid — BEIDE haben im Event die 10.254.1.2 (nie gleichzeitig). Der DNS-Eintrag passt also für beide.
- Die aktive Box beantwortet den Check auf Port 80 (App auf 3002 bleibt unberührt):
Odroid (Linux + nginx): Locations in den BESTEHENDEN Default-Block auf :80 (nicht in einen eigenen server_name-Block — sonst matcht ein curl-per-IP nicht!):
location = /generate_204 { return 204; }
location = /gen_204 { return 204; }
location = /connecttest.txt { default_type text/plain; return 200 "Microsoft Connect Test"; }
location = /hotspot-detect.html { default_type text/html; return 200 "<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>"; }
→ sudo nginx -t && sudo systemctl reload nginx
Deploy per Ansible (über Port-Forward 192.168.178.206:2222, s. § 9c).
Windows (Node, kein nginx): kleiner Port-80-Responder, beim App-Start mit hoch, mit EADDRINUSE-Abfangen (derselbe Code läuft auch auf dem Odroid — dort hält nginx :80, der Node-Responder überspringt sich dann):
http.createServer(...).listen(80) // /generate_204, /gen_204 = 204
server.on('error', e => e.code==='EADDRINUSE' && skip) // nginx hat :80
Test:
curl -i http://10.254.1.2/generate_204→ "204 No Content". ACHTUNG server_name-Falle: liegt der 204-Block in einem eigenen server_name-Block, matcht curl-per-IP NICHT (Host = IP ≠ Domain) → 404 trotz korrekter Config. Darum in den Default-Block (Host-egal). Danach am Tablet: DTLWLAN_5G VERGESSEN + neu verbinden (Android cached den alten Check!) + Privates DNS am Tablet AUS (DoH umgeht den lokalen Eintrag). Clients müssen das Gateway als DNS nutzen (per DHCP Standard). Pfad für die DNS-Einträge: "Routing → DNS" (nicht intuitiv).
9c. Admin-Zugriff für Ansible (Port-Forward von der WAN-Seite)¶
Topologie: Admin-Desktop im FritzBox-Hausnetz (192.168.178.0/24), die CGU mit ihrer WAN-Seite ebenfalls dort (192.168.178.206). Das Event-Netz liegt HINTER der CGU. Desktop → Event-Netz ist also WAN→LAN und standardmäßig geblockt.
Kein Admin-SSID nötig (und auf 5 GHz ist das SSID-Limit eh erreicht). Lösung: ein einzelner Port-Forward auf der CGU. Desktop bleibt im Hausnetz.
CGU → Settings → Port Forwarding → Create:
Name: Ansible-Odroid
From: 192.168.178.13 (nur der Admin-Desktop)
WAN Port: 2222 (eigener Port, kollidiert nicht mit CGU-SSH)
Forward IP: 10.254.1.x (ODROID auf VLAN 1 — NICHT die WAN-IP .206!)
Forward Port: 22
Protocol: TCP
Warnung "WAN1 is behind NAT ... forward on upstream router" IGNORIEREN: gilt nur für Zugriff aus dem echten Internet. Der Desktop sitzt im SELBEN Subnetz wie die CGU-WAN-IP und erreicht .206:2222 direkt — keine FritzBox-Weiterleitung nötig.
Vom Desktop:
ssh-copy-id -p 2222 <user>@192.168.178.206 # Key hinterlegen
ssh -p 2222 <user>@192.168.178.206 # Test
Ansible-Inventory (auf WAN-IP + Forward-Port zeigen, nicht auf die Odroid-IP):
Voraussetzung: Odroid feste IP auf VLAN 1, CGU-WAN-IP feste DHCP-Reservierung in der FritzBox (sonst zeigt der Forward irgendwann ins Leere). Weitere Ziele im Event-Netz — je eigener WAN-Port (2223, …); bei vielen Zielen lohnt stattdessen eine statische Route in der FritzBox + NAT-Ausnahme auf der CGU.
10. Phase 7 — RUT901 konfigurieren (Dual-SIM)¶
Stand (Pfingsten 2026): O2-Pfad LIVE — SIM 1 registriert, Operator "o2-de" (anfangs "Willkommen" = Welcome-/Übergangsname, nach Reboot korrekt), Internet getestet (spiegel.de lädt). LAN-IP = 192.168.99.1. Anruf-Empfang im O2-Portal aus + RUT Incoming Calls = Reject + LTE-only gesetzt (s.u.). OFFEN: 1NCE (Slot 2) noch per Post unterwegs — dann APN iot.1nce.net + Failover-Test; danach RUT-LAN an CGU LAN4 (=WAN2) + Gesamt-Failover-Test. Firmware bereits aktuell.
Web-UI unter 192.168.1.1 (Default des RUT901 — anpassen, damit kein
Konflikt mit CGU):
- RUT901 LAN-IP auf 192.168.99.1 lassen/setzen (bewusst separat vom
10.254.x-LAN-Schema und von WAN1/Heim-Subnetz -> kein Overlap am CGU-WAN2)
- SIM1: O2-Multicard einlegen (Slot 1, primär)
- SIM2: 1NCE einlegen (Slot 2, Failover)
- WLAN: DEAKTIVIEREN (Network → Wireless → off)
→ verhindert Interferenz mit den U6 Mesh
- RUT901 LAN-Port → CGU LAN4 (=WAN2)
- WAN-Port des RUT901: leer lassen
APN je SIM (Auto-APN AUS, manuell — wegen Drop-Reviews!):
Network → Mobile → General
- SIM1 (O2): APN "internet" (oder O2-Business-APN aus Vertragsunterlagen)
- SIM2 (1NCE): APN "iot.1nce.net" (kein User/Passwort)
Anrufe von der Datenleitung fernhalten (wichtig bei O2-Multicard!):
Eine O2-Multicard klingelt per "Parallel Ringing" auf ALLEN eingebuchten Karten — ein eingehender Anruf kann die Router-Datenverbindung unterbrechen. Dreifach absichern:
- O2 Business Easy Access: Anruf-Empfang für die Router-SIM ausschalten
→ O2 routet erst gar keine Anrufe auf die Karte (Alternative: USSD *124#)
- RUT: Services → Mobile Utilities → Incoming Calls → Action: Reject
→ Router weist eingehende Anrufe auf Geräteebene ab
- SIM1: Network → Mobile → SIM1 → Network Type = 4G (LTE) only
→ kein CSFB-Abtauchen auf 2G/3G, Daten bleiben stabil
Dual-SIM Auto-Failover:
Network → Mobile → SIM Switch
- Primär: SIM1 (O2)
- Auto-Switch auf SIM2 bei: schwaches Signal / kein Netz /
Datenverbindung fehlgeschlagen
- Switch-back auf SIM1: AN
→ kehrt zu gratis O2 zurück, sobald O2 wieder verfügbar (spart 1NCE-Daten)
- Switch-Zeit ~10–30 s (Netzwechsel, KEIN Reboot — Sekunden statt Minuten)
Recovery-Kette: O2 schwach → RUT901 wechselt in Sekunden auf 1NCE → 1NCE roamt aufs beste Netz (Telekom/Vodafone/O2) → Retry-Queue schickt gequeuete Wertungen sofort nach. Keine Minuten-Lücken mehr.
Double-NAT (RUT901 NATet, CGU NATet) ist für reinen JSON-Upload egal.
Externe Antenne (Hallen-Empfang): Magnetfuß-LTE-Antenne an die beiden SMA-"MOBILE"-Anschlüsse, ans Fenster/nach draußen legen.
10a. Connection-Watchdog (Ping Reboot) — als Last-Resort¶
Mit Dual-SIM ist der Failover die primäre, schnelle Erholung (Sekunden, ohne Reboot). Der Watchdog ist nur noch das letzte Netz, falls BEIDE SIMs ausfallen oder der Router hängt (Community berichtet von seltenen Hängern):
Services → Auto Reboot → Ping Reboot
- Enable: AN
- Ping IP-Adresse: 1.1.1.1 (oder 8.8.8.8)
- Ping-Intervall: 60 s
- Fehlversuche bis Reboot: 5 (→ Reboot erst nach ~5 Min Totalausfall)
- Interface: Mobile (wwan)
- Speichern
Reihenfolge der Erholung: 1) Dual-SIM-Failover (Sekunden) → 2) wenn beide SIMs tot: Watchdog-Reboot (~1–2 Min) als letzter Ausweg. Im Normalbetrieb greift fast immer der Failover, der Reboot bleibt theoretisch.
10b. Firmware-Disziplin¶
RutOS-Updates haben gelegentlich QC-Bugs (kaputtes WebUI, WAN-Config-Fehler nach Update). Deshalb:
- Eine stabile Firmware ZU HAUSE aufspielen und durchtesten
- NICHT direkt vor einem Event updaten
- Funktionierende Version notieren/behalten (Rollback-Option)
- Vor Update immer Config-Backup ziehen (System → Backup)
Zusammen mit dem manuellen APN (oben) und der JSON-Retry-Queue im Backend sind damit alle drei in den Reviews genannten Schwachstellen abgedeckt.
11. Phase 8 — Sichern & als Template¶
- Settings → System → Backups → Download Backup (.unf)
- Site umbenennen: "Wettkampf-Standard"
- Backup an festen Ort (Cloud + lokal) — Basis für jedes Event
12. Event-Auf-/Abbau-Checkliste¶
Aufbau:
- CGU + USW + RUT901 aus Koffer, Stromversorgung
- Falls Hallen-Kabel-Internet vorhanden: ans CGU WAN
- APs auf Walimex-Stative, an die Tischenden, 15–20° in die Halle gewinkelt
- APs per PoE+ an USW
- Server an USW (LAN2 / via Switch)
- Booten lassen, im UniFi-Dashboard prüfen: alle Geräte grün
- 1–2 Tablets testweise verbinden, Wertungs-Webapp + Socket-Verbindung prüfen
- RSSI der entferntesten Kampfrichter-Position checken (Ziel: besser als -75 dBm)
- JSON-Testupload auslösen, im Ergebnisdienst prüfen
- Profil-B-SSIDs (…AP1/AP2) pausiert — außer es ist ein Großevent
- Wertungs-Tablets: nur DTLWLAN_Unifi5G gespeichert, fremde/Hallen-WLANs vergessen
- Geräte mit SIM: Auto-Wechsel zu Mobilfunk aus (sonst Absprung bei "kein Internet")
Abbau:
- Geräte herunterfahren / Strom trennen
- Kabel beschriftet aufrollen, Stative einklappen
- APs vorsichtig von Adaptern lösen
13. Anhang — Hallen-WLAN als zusätzlicher Uplink (optional)¶
Der RUT901 kann sich als WLAN-Client (Station-Mode / WiFi-as-WAN) in ein vorhandenes Hallen-WLAN einhängen und dessen Internet weiterreichen — entweder als Notnagel (kein Kabel/LTE) ODER als primärer Uplink, um LTE-Datenvolumen zu sparen.
- ZUERST PRÜFEN: Bietet das Hallen-WLAN 2,4 GHz? Der RUT901 funkt NUR auf
2,4 GHz (WiFi 4, 802.11b/g/n) — ein reines 5-GHz-Netz sieht er NICHT.
- RUT901 → Network → Wireless → SSIDs → Client/Station (STA) → Scan
- Hallen-SSID auswählen, Passwort eingeben, verbinden
- Als WAN nutzbar machen: STA-Interface in die WAN-Failover-Gruppe aufnehmen
- Priorität setzen: WiFi-STA VOR Mobile (LTE) — spart O2/1NCE-Daten,
LTE bleibt automatischer Rückfall, wenn das Hallen-WLAN wegbricht
- Falls Captive Portal (Login-/Akzeptierseite): headless meist nicht
durchklickbar — dann NICHT nutzbar, auf LTE bleiben
Das Internet landet — egal ob aus Hallen-WLAN oder LTE — immer als WAN2 in der CGU. Ein echtes Hallen-KABEL an CGU-WAN1 hätte weiterhin Vorrang. Stolpersteine: (1) 2,4-GHz-Pflicht, (2) Captive Portal, (3) fremde, evtl. gedrosselte/überlastete Bandbreite. Für den winzigen JSON-Upload reicht es, als alleiniger Anker ist es aber unzuverlässig — LTE bleibt der Boden.
Vorher erledigen (zu Hause):
- WiFi-Antennen montieren! RUT901 hat getrennte LTE- (2×) und WiFi- (2×)
Anschlüsse — für WiFi-as-WAN müssen die WiFi-Antennen dran sein, sonst
kaum Empfang. (Bei reiner LTE-Inbetriebnahme oft vergessen.)
- WiFi-Radio aktivieren (Network → Wireless) — bei LTE-Only-Setup oft aus
- TROCKENÜBUNG mit Heim-WLAN (Klickweg s. unten) — einmal komplett durchspielen,
dann ist vor Ort nur noch "anderes WLAN auswählen"
- Check: Hallen-WLAN-Subnetz ≠ 192.168.99.x (RUT-LAN), sonst WAN/LAN-Konflikt
Unverändert bleiben: LTE-Konfig (APNs, LTE-only, Anruf-Reject), LAN-IP 192.168.99.1, CGU-WAN2-Kette. WiFi-STA ist nur ein zusätzliches WAN; NAT macht der RUT automatisch, keine extra Firewall-Regel nötig.
Trockenübung Schritt für Schritt (RUT per LAN-Kabel auf 192.168.99.1 konfigurieren — NICHT übers Heim-WLAN, sonst reißt die Admin-Verbindung beim Test ab; oben im WebUI "Advanced"-Modus einschalten, sonst fehlt Failover):
1) WiFi-Client anlegen:
Network → Wireless → "Scan" → 2,4-GHz-Heim-WLAN wählen → Passwort
→ verbinden, Interface als WAN deklarieren (entsteht als "wwan")
2+3) Failover & Priorität:
Network → WAN (oder Network → Failover)
→ Failover aktivieren, WiFi per Drag & Drop ÜBER Mobile ziehen → Save & Apply
(oben in der Liste = höhere Priorität)
4) Test:
Status prüfen: aktives WAN = WiFi?
whatsmyip.com → IP merken
WiFi-Client per Toggle DEAKTIVIEREN (simuliert "Hallen-WLAN weg")
→ RUT fällt nach Sekunden auf Mobile/LTE → whatsmyip = andere IP = Failover ok
WiFi-Client wieder aktivieren → RUT springt zurück auf WiFi
Der Toggle-Trick (STA-Interface aus/an) ist besser als den Heim-Router auszuschalten — simuliert den WLAN-Wegfall, ohne das übrige Heimnetz lahmzulegen.