← Heimnetz-Übersicht · Netzwerk Raderbroich und Arcen · HA Arcen

Stand: 09.10.2026 – nach dem Umbau vor Ort (zweiter Uplink Landal, Huawei bevorzugt, gesamter Verkehr durch den Tunnel).

Hinweis: Auf dieser Seite stehen bewusst keine Schlüssel und keine WLAN-Passwörter. Diese stehen nur auf dem Router selbst bzw. in der Passwortverwaltung.

Alle Geräte im Chalet gehen über den Tunnel und die FRITZ!Box in Raderbroich ins Internet. Nach außen erscheint die öffentliche Adresse des Kabelanschlusses in Raderbroich. Huawei und Landal transportieren nur noch den verschlüsselten Tunnel.

connectify-nb auf 5 GHz wurde am 09.10.2026 entfernt, das 5-GHz-Funkteil dient jetzt nur noch als Client am Landal-WLAN. Eigenes 5-GHz-WLAN gibt es damit nicht mehr.

Alle drei eigenen SSIDs landen im selben Netz lan – es gibt keine Trennung zwischen IoT- und normalen Geräten.

Der starke Zugangspunkt lehnt die Verbindung ab. Im Log steht AP appears to change mode (expected HE, found VHT), disconnect. Das passiert unabhängig von der Verschlüsselung (getestet: psk2, psk2+ccmp, psk-mixed) und auch mit Funkmodus VHT80. Das installierte wpad-basic-mbedtls kann den HE-Modus für Clients nicht abschalten. Der Router nimmt deshalb von selbst den schwächeren Zugangspunkt.

Folge: Die Ersatzleitung ist langsam (gemessen ca. 0,8 Mbit/s durch den Tunnel, Ping um 600 ms). Sie reicht für Home Assistant und Fernzugriff, nicht für Streaming.

Scan selbst ausführen: iwinfo phy1-sta0 scan.

Weil der gesamte Verkehr durch den Tunnel läuft, genügt es, den Weg des Tunnels umzulegen. Das macht ein kleines Skript, das als Dienst läuft.

Zustand ansehen:

cat /tmp/uplink-watchdog.state
logread -e uplink-watchdog

uplink=wwan heißt Huawei, uplink=wwan2 heißt Landal.

Getestet am 09.10.2026: simulierter Huawei-Ausfall → Tunnel nach ca. 30 s über Landal, Internet lief weiter; nach Ende der Störung zurück auf Huawei. Nach einem Neustart des Routers stand der Tunnel nach rund einer Minute von selbst.

Wichtig für die Schnittstelle fritzbox: nohostroute ist gesetzt, die Route zum Endpunkt verwaltet allein der Dienst. Ohne laufenden Dienst kommt der Tunnel nach einem Neustart nicht hoch.

Die FRITZ!Box leitet Internetverkehr aus dem Tunnel weiter (getestet am 09.10.2026). An der FRITZ!Box wurde nichts geändert.

Folgen des vollen Tunnels:

• Fällt die FRITZ!Box oder der Kabelanschluss in Raderbroich aus, hat das Chalet kein Internet, auch wenn Huawei und Landal funktionieren.
• Die Geschwindigkeit im Chalet ist durch den Upload des Kabelanschlusses in Raderbroich begrenzt.
• Nur IPv4 läuft durch den Tunnel. Das LAN hat kein öffentliches IPv6.
• Namensauflösung: Der Router fragt 8.8.8.8 (durch den Tunnel) und die DNS-Server von Huawei und Landal direkt. DNS-Anfragen können also am Tunnel vorbei gehen.

Weiterleitungen: lan → wan, lan ↔ wireguard, wireguard → wan, wan → wireguard, lan ↔ bridge_zone.

Sonst die Standardregeln von OpenWrt (DHCP, Ping, IGMP, ICMPv6, IPsec).

Weil die Zone wireguard NAT macht, sehen Geräte in Raderbroich alle Zugriffe aus Arcen als vom Router 10.10.11.1 kommend, nicht von der einzelnen Geräteadresse.

Momentaufnahme der DHCP-Geräte (02.10.2026):

• LuCI im Browser: http://10.10.11.1 (aus Raderbroich über den Tunnel erreichbar)
• SSH: ssh root@10.10.11.1
• Claude (SSH-MCP) vom MacBook: Schlüssel ~/.ssh/openwrt_claude, Eintrag openwrt in ~/Library/Application Support/Claude/claude_desktop_config.json.
  • Über den MCP-Zugang geht nur Lesen. Schreibende Befehle verlangen eine Freigabe, die in der Projekt-Ansicht nicht gestellt werden kann. Der Umbau am 09.10.2026 lief deshalb mit ausdrücklicher Erlaubnis direkt per ssh mit dem Schlüssel.
  • Der Eintrag muss innerhalb von „mcpServers“ stehen. Stand er am 02.10. außerhalb, startete der Server nicht, und es gab auch keine Log-Datei.
  • Log: ~/Library/Logs/Claude/mcp-server-openwrt.log
  • Nach Änderungen an der Datei Claude mit Cmd+Q beenden und neu starten.
• Ist das MacBook nicht im Chalet-WLAN, sondern direkt am Huawei oder im Landal-WLAN, ist der Router über das VPN des MacBooks nach Raderbroich trotzdem erreichbar.

Der Stand vor dem Umbau liegt auf dem Router in /root/backup-20261009/ (network, wireless, firewall, dhcp, rc.local).

/root/umbau-rollback.sh now

Das stoppt und deaktiviert uplink-watchdog, spielt network, wireless und firewall zurück und startet Netzwerk und Firewall neu. Danach gilt wieder: nur Huawei, connectify-nb auf 2,4 und 5 GHz, Tunnel nur für die Netze in Raderbroich.

• Landal nur schwach angebunden: Der starke Zugangspunkt am Chalet verweigert die Verbindung (siehe WLAN). Mögliche Wege: Firmware-Update des Routers (ob das hilft, ist ungeprüft) oder wpad in einer Variante, die HE für Clients abschalten kann.
• SSH mit Passwort erlaubt, auch für root (PasswordAuth und RootPasswordAuth an). Ziel: nur Schlüssel.
• Tunnel-Adresse = LAN-Adresse: fritzbox hat ebenfalls 10.10.11.1/24. Dadurch gibt es zwei Routen für 10.10.11.0/24. Funktioniert derzeit, sauberer wäre 10.10.11.1/32 am Tunnel.
• Netz 10.10.12.0/24 in den AllowedIPs – klären, wofür es gedacht ist.
• Zone bridge_zone enthält ebenfalls lan – doppelte Zone, vermutlich überflüssig.
• Weiterleitung wan → wireguard ist erlaubt – vermutlich nicht nötig.
• Weiterleitung lan → wan besteht noch. Im Normalbetrieb geht nichts am Tunnel vorbei, weil die Standardroute in den Tunnel zeigt. Wer das hart erzwingen will, entfernt diese Weiterleitung.
• WLAN-Verschlüsselung WPA/WPA2 gemischt, einfache Schlüssel. Besser WPA2 (oder WPA2/WPA3) mit stärkeren Schlüsseln.
• Keine Trennung der IoT-SSIDs vom übrigen LAN.
• Alter, deaktivierter WireGuard-Peer kann entfernt werden.
• Hostname ist OpenWrt – evtl. auf openwrtone ändern, damit er zum Wiki passt.

Der Dienst uplink-watchdog meldet den aktuellen Uplink per Webhook an Home Assistant Arcen (http://10.10.11.12, Port 80): bei jedem Wechsel sofort, sonst alle 5 Minuten.

Die Webhook-Adresse steht im Skript /usr/sbin/uplink-watchdog in der Variable HA_HOOK. Getestet am 09.10.2026 mit einem simulierten Huawei-Ausfall: Anzeige wechselte auf Landal und wieder zurück.

Ist das Tagesvolumen des Huawei verbraucht, bleibt er „online“, wird aber sehr langsam. Der Dienst uplink-watchdog erkennt das seit dem 09.10.2026 über einen kleinen Test-Download.

Dafür ist das Paket curl installiert. Nach einem Firmware-Update fehlt es wieder (opkg update && opkg install curl); ohne curl läuft der Dienst weiter, nur ohne Geschwindigkeitsvergleich.

Messwerte am 09.10.2026: Huawei 420–610 kB/s, Landal direkt 140–460 kB/s. Getestet mit künstlich auf 10 kB/s gebremstem Huawei: Wechsel auf Landal und nach Ende der Bremse zurück.

In /tmp/uplink-watchdog.state stehen dazu huawei_gedrosselt, huawei_kbs, landal_kbs und grund.

• input_text.router_uplink_grund enthält den Grund (z. B. „Huawei gedrosselt 10 kB/s, Landal 460 kB/s“), die Karte „Internet“ zeigt ihn an.
• Automation „System: Router-Uplink-Wechsel melden“ schickt bei jedem Wechsel eine Telegram-Nachricht nur an Norbert; ist „Telegram aktiv“ aus, ersatzweise einen Push auf sein iPhone.

Die vorige Fassung des Skripts liegt in /root/backup-20261009/uplink-watchdog.v1.

Das ersetzt die Aussagen weiter oben zur schwachen Landal-Anbindung. Der Router hängt jetzt am nahen Zugangspunkt 3C:46:A1:BE:A5:B0 (Kanal 116, -46 dBm). Gemessen direkt über Landal: ca. 20–40 Mbit/s, kein Paketverlust, Ping um 20 ms. Zum Vergleich der Huawei zur selben Zeit: ca. 6 Mbit/s.

Ursache des früheren Abbruchs: Die Landal-Zugangspunkte kündigen Wi-Fi 6 (HE) an, antworten beim Verbinden aber nur mit Wi-Fi 5 (VHT). Der Treiber (mt76/mac80211) bricht dann ab: AP appears to change mode (expected HE, found VHT), disconnect. Verschlüsselung und Cipher spielen dabei keine Rolle; die Cipher-Einstellung aus LuCI landet bei WLAN-Clients ohnehin nicht in der erzeugten Konfiguration.

Lösung: Für den Client mit der SSID Free WiFi Landal wird VHT abgeschaltet (disable_vht=1), damit entfällt auch HE; die Verbindung läuft per HT mit 40 MHz (Verbindungsrate 270 Mbit/s). Dafür steht eine eigene Zeile in /lib/netifd/hostapd.sh in der Funktion wpa_supplicant_add_network (Kommentar „Eigene Anpassung 09.10.2026“). UCI/LuCI hat dafür keine Einstellung.

• Original der Datei: /root/backup-20261009/hostapd.sh.orig
• Nach einem Firmware-Update ist die Zeile weg und muss neu eingetragen werden, sonst verbindet sich der Router wieder nur mit einem schwachen Zugangspunkt. Mit neuerer Firmware vorher prüfen, ob der Abbruch überhaupt noch auftritt.
• Ein Tausch von wpad-basic-mbedtls gegen wpad-mbedtls war nicht nötig und hätte nichts gebracht: Auch die Vollversion kennt kein disable_he.
• Im Client ist keine BSSID fest eingetragen; der Router wählt selbst den stärksten Zugangspunkt.

Selbst messen: landal-test auf dem Router (bzw. vom MacBook ssh -i ~/.ssh/openwrt_claude root@10.10.11.1 landal-test) zeigt Zugangspunkt, Signal, drei Messungen und Paketverlust. Verbraucht 3 MB über Landal.

Hinweis LuCI: Beim Client nie „Scan → Netzwerk beitreten“ mit dem vorgeschlagenen Netz wwan verwenden. Am 09.10.2026 entstand so ein zweiter Eintrag am Netz wwan; kurz darauf verlor der Router seine Huawei-Verbindung. Wenn überhaupt, als Netz wwan2 angeben.

Das ersetzt die Regel „Huawei bevorzugt“ und die Drossel-Erkennung weiter oben. Skript /usr/sbin/uplink-watchdog (dritte Fassung; Vorgänger in /root/backup-20261009/uplink-watchdog.v1 und .v2).

• Landal, solange es schneller ist. Huawei, wenn Landal langsamer als der Huawei ist oder kein Internet hat.
• Fällt einer der beiden aus (3 Fehl-Pings in Folge, ca. 30 s), läuft der Tunnel über den anderen; zurück nach ca. 60 s stabilen Pings.
• Wechsel von Landal zu Huawei erst, wenn der Huawei mindestens 20 % schneller ist; zurück zu Landal, sobald Landal schneller ist.

Getestet am 09.10.2026: Landal künstlich auf 30 kB/s gebremst → Wechsel auf Huawei (829 kB/s); Bremse weg → zurück auf Landal (2303 kB/s).

/tmp/uplink-watchdog.state zeigt jetzt uplink (Huawei/Landal), bevorzugt, huawei_internet, landal_internet, huawei_kbs, landal_kbs, grund.

• input_number.router_huawei_geschwindigkeit und input_number.router_landal_geschwindigkeit (Mbit/s), vom Webhook gefüllt.
• Die Karte „Internet“ zeigt beide Geschwindigkeiten, den Grund und seit wann.
• Telegram bei jedem Wechsel nur an Norbert, mit Grund.

10.10.12.0/24 ist das Netz hinter dem zweiten OpenWrt-Router im Chalet (10.10.12.1, SSID nb.tv). Damit ist der frühere offene Punkt geklärt.

Auf openwrtone geändert am 09.10.2026:

• 10.10.12.0/24 aus den AllowedIPs des Tunnels entfernt (das Netz liegt lokal, nicht in Raderbroich).
• Statische Route nbtv: 10.10.12.0/24 über 10.10.11.2 (Schnittstelle lan).
• Stand vorher: /root/backup-20261009/network.vor-nbtv-route.

Noch offen auf dem zweiten Router: feste Adresse 10.10.11.2 im Chalet-Netz und Firewall-Zone wan für Zugriffe aus 10.10.11.0/24 öffnen (Eingehend und Weiterleiten annehmen, Weiterleitung nach lan). Erst dann ist 10.10.12.0/24 aus dem Chalet-Netz erreichbar.

Zweiter Router (nb.tv): hängt als WLAN-Client an connectify-nb (2,4 GHz), MAC 20:05:b6:01:ea:22, feste DHCP-Zuordnung 10.10.11.108 (dhcp.nbtv). Die Route nbtv für 10.10.12.0/24 zeigt auf 10.10.11.108 (nicht mehr .2 wie weiter oben). Zusätzlich NAT-Regel nbtv_nat in der Firewall: Zugriffe aus dem Chalet-Netz nach 10.10.12.0/24 gehen unter der Adresse 10.10.11.1 hinaus. Stand: 10.10.12.1 antwortet auf Ping; SSH/Web und die Geräte dahinter erst, wenn auf dem zweiten Router die Firewall-Zone wan geöffnet ist.

WLAN-Geräte untereinander: Geräte am selben Zugangspunkt (z. B. MacBook und Klimaanlage an connectify-nb) konnten sich nicht direkt erreichen. Ursache: /lib/netifd/netifd-wireless.sh setzt für jeden AP in einer Brücke ap_isolate=1 und überlässt die Weiterleitung der Brücke (Hairpin); das funktionierte auf diesem Gerät nicht. Geändert:

• wifinet1, wifinet3, wifinet4: multicast_to_unicast '0' und isolate '0'
• In /lib/netifd/netifd-wireless.sh (Funktion _wireless_set_brsnoop_isolation) die Vorgabe von multicast_to_unicast von 1 auf 0 gestellt (Kommentar „Eigene Anpassung 09.10.2026“). Original: /root/backup-20261009/netifd-wireless.sh.orig. Nach einem Firmware-Update ist auch diese Zeile weg.
• Ergebnis: kein ap_isolate mehr in /var/run/hostapd-phy0.conf, die Weiterleitung zwischen WLAN-Geräten macht das Funkteil selbst.

OpenWrt One, OpenWrt 24.10.5, Hostname OpenWrt. LAN 10.10.12.1/24, WLAN nb.tv auf 5 GHz (Kanal 36). Uplink: WLAN-Client connectify-nb auf 2,4 GHz (Netz wwan, DHCP, bekommt fest 10.10.11.108). Ein zweiter Client-Eintrag für „Free WiFi Landal“ ist vorhanden, aber deaktiviert. Eine WireGuard-Schnittstelle fritzbox ist konfiguriert, aber nicht aktiv.

Geändert am 09.10.2026 (Sicherung auf dem Gerät: /root/backup-20261009/firewall):

• Firewall-Zone wan: Eingehend und Weiterleiten auf annehmen
• Weiterleitung wan → lan ergänzt

Damit sind 10.10.12.1 (LuCI, SSH) und die Geräte dahinter aus dem Chalet-Netz 10.10.11.0/24 erreichbar. Getestet vom Hauptrouter: 10.10.12.105 (gbip4k), .148 (Korschenbroich), .220, .234 antworten auf Ping. Die Zone wan dieses Routers ist das eigene Chalet-Netz, nicht das Internet; sollte er je direkt an ein fremdes Netz (z. B. Landal) gehängt werden, muss die Zone wieder geschlossen werden.

SSH-Zugang: mit dem normalen Schlüssel des MacBooks (~/.ssh/id_ed25519), nicht mit openwrt_claude.

Beide haben OpenWebif auf Port 80 und SSH mit dem Schlüssel des MacBooks.

Zweiter Router, zusätzliche Firewall-Regel chalet_nat: Zugriffe aus 10.10.11.0/24 ins Netz 10.10.12.0/24 gehen unter der Adresse 10.10.12.1 hinein. Nötig, weil OpenWebif des Clients fremde Netze mit „403.6 IP address rejected“ abweist. Sicherung: /root/backup-20261009/firewall.vor-lan-nat auf dem zweiten Router.

Home Assistant Arcen:

• Integration Enigma2 zweimal eingerichtet (10.10.12.105 und 10.10.12.220, Port 80, ohne Anmeldung).
• Entitäten: media_player.sat_client („Sat-Client“) und media_player.unnamed_device (Sat-Server). Der Server lässt sich nicht umbenennen: Er hängt per WLAN und meldet keine MAC-Adresse, deshalb vergibt Home Assistant keine eindeutige Kennung.
• Automation „TV: Sat-Server nach dem Hochfahren in Standby“: Wird der Server erreichbar und ist an (Wechsel von nicht erreichbar auf an), wartet sie 30 s und schaltet ihn in Standby. Wer ihn später von Hand einschaltet, wird nicht übersteuert.
• Kacheln für beide Receiver in der Unteransicht „Steckdosen“.

Ist die Steckdose „Fernseher“ aus, sind der zweite Router und damit das ganze Netz 10.10.12.0/24 weg; beide Receiver zeigen dann in Home Assistant „nicht verfügbar“.

• In HA Arcen gibt es die Auswahl input_select.router_uplink_vorgabe (Auto, Huawei, Landal), Karte „Internet-Zugang wählen“ auf der Hauptansicht.
• Automation „System: Router-Uplink-Vorgabe an Router senden“ ruft bei jeder Änderung http://10.10.11.1/cgi-bin/uplink-mode?mode=auto|huawei|landal auf (Integration Downloader, Zielordner /share, Datei router-uplink-vorgabe.txt).
• Beim Start von Home Assistant und zu jeder vollen Stunde stellt dieselbe Automation wieder auf Auto.
• Router: /www/cgi-bin/uplink-mode nimmt die Vorgabe nur von 10.10.11.12 an und schreibt sie nach /tmp/uplink-mode. Nach einem Router-Neustart fehlt die Datei, dann gilt Auto.
• /usr/sbin/uplink-watchdog (Fassung 4, Vorgänger unter /root/backup-20261009/uplink-watchdog.v3) liest die Vorgabe alle 10 Sekunden. Auch bei fester Vorgabe gilt: Hat der gewählte Uplink kein Internet, läuft der Tunnel über den anderen. In der Zustandsdatei steht die Zeile vorgabe=, als Grund erscheint „Manuell eingestellt“.
• Beide Dateien stehen in /etc/sysupgrade.conf.

• Der Sat-Client 10.10.12.220 hat zwei zusätzliche Bouquets, jeweils an erster Stelle: „FRITZ!Box Kabel (TV)“ (35 HD, 66 SD) und „FRITZ!Box Kabel (Radio)“ (99 Sender). Dateien: /etc/enigma2/userbouquet.fritzbox_tv.tv und userbouquet.fritzbox_radio.radio.
• Quelle sind die Senderlisten der FRITZ!Box (http://192.168.192.1/dvb/m3u/tvhd.m3u, tvsd.m3u, radio.m3u), als RTSP-Einträge mit Diensttyp 4097. Ändert der Kabelanbieter Frequenzen, müssen die Bouquets neu erzeugt werden.
• Der Strom läuft durch das VPN und nur per UDP (TCP lehnt die FRITZ!Box ab). Ein HD-Sender braucht etwa 5,5 Mbit/s, also rund 2,5 GB pro Stunde.
• Sicherung der alten Bouquet-Listen auf dem Client: /home/root/backup-20261010/.

• Auf dem zweiten Router: ssh root@10.10.12.1 sat-test lädt dreimal eine 60-MB-Datei vom Sat-Server und zeigt Signal, Rate und Wiederholungen der Funkstrecke zum Sat-Server.
• Die Testdatei liegt auf dem Sat-Server unter /home/root/speedtest.bin.
• Messwerte 10.10.2026: etwa -70 dBm, 80 bis 90 Mbit/s, 9 bis 13 % Wiederholungen. Kanal 36 mit 80 MHz war die beste Einstellung.

Beide Router laufen jetzt auf OpenWrt 25.12.5 (openwrtone vorher 24.10.0, Router nb.tv vorher 24.10.5). Die Paketverwaltung ist ab 25.12 apk statt opkg (apk add, apk update, apk list -I).

Sicherungen vor dem Update: Sicherungen.

Die Änderungen an /lib/netifd/hostapd.sh (Landal: disable_vht=1) und /lib/netifd/netifd-wireless.sh (multicast_to_unicast Vorgabe 0) gehen bei jedem Firmware-Update verloren. Dafür gibt es jetzt das Skript /usr/sbin/anpassungen-anwenden:

• trägt beide Anpassungen wieder ein, prüft die Syntax, sichert die Originale als *.orig-vor-anpassung und ist mehrfach ausführbar
• steht in /etc/sysupgrade.conf und läuft beim ersten Start nach einem Update über /etc/uci-defaults/99-anpassungen-20261010
• nach apk upgrade von netifd oder hostapd von Hand ausführen, danach wifi reload

• Dateibesitzer: Das Wiederherstellungs-Archiv wurde auf dem Mac gebaut, die Dateien gehörten dadurch dem Mac-Benutzer statt root. Dropbear lehnte darum authorized_keys ab, kein SSH per Schlüssel. Behoben mit chown -R root:root /etc /usr/sbin /usr/bin /www /root /lib/netifd und chmod 600 /etc/dropbear/authorized_keys. Archive künftig mit tar –owner=0 –group=0 bauen oder direkt auf dem Router.
• Tunnel ohne Daten (0 Byte): uplink-watchdog war nach dem ersten Start nicht gestartet. Ohne seine Host-Route zum Tunnel-Endpunkt (nohostroute ist gesetzt) läuft das Tunnelpaket in den Tunnel selbst. Nach manuellem Start des Dienstes stand der Tunnel (Handshake, FRITZ!Box erreichbar).
• Offen: Warum der Dienst beim Booten nicht startete, ist nicht geklärt. Der Link /etc/rc.d/S99uplink-watchdog ist vorhanden. Neustart-Test steht aus. Bis dahin nach jedem Neustart prüfen: ps | grep uplink-watchdog. Der tägliche Neustart um 04:30 testet es von selbst.
• Die FRITZ!Box wurde dabei von Hand neu gestartet; sie war nicht die Ursache.

• Neustart-Test bestanden: uplink-watchdog startete von selbst, der Tunnel stand nach ca. 1 Minute mit Handshake, FRITZ!Box und Internet erreichbar. Der oben genannte offene Punkt (Dienst startet nicht beim Booten) trat dabei nicht wieder auf. Ursache des ersten Ausfalls vermutlich die falschen Dateibesitzer direkt nach dem Update.
• Umschaltung getestet: Vorgabe Huawei, Landal und Auto über /tmp/uplink-mode wurden jeweils innerhalb von etwa 10 Sekunden übernommen, Route zum Endpunkt und Tunnel folgten, Anzeige „Manuell eingestellt“ bzw. „Landal schneller“ stimmte.
• Home-Assistant-Anzeige (input_select.router_uplink), Geschwindigkeitsmessung (curl), WLANs, DHCP, Netz nb.tv mit NAT und Cron-Neustart 04:30 geprüft und in Ordnung.

Alle Archive sind verschlüsselt, Details und Prüfsummen auf Sicherungen.

Der Dienst tunnel-failover (Skript /usr/sbin/tunnel-failover, Init /etc/init.d/tunnel-failover, beide in /etc/sysupgrade.conf) wählt, wie der Router ins Netz geht. Er ergänzt uplink-watchdog, der weiter Huawei/Landal wählt.

• Prüfung alle 10 s: Ping durch den jeweiligen Tunnel auf 192.168.192.1 bzw. Server 10.10.20.1 und auf 1.0.0.1 (Internet). Die Pings laufen per Policy-Routing (Regeln 100 bis 102, Tabellen 100 und 101) immer durch genau diesen Tunnel, egal welche Stufe aktiv ist.
• Wechsel nach unten nach 3 Fehlschlägen in Folge (ca. 30 bis 40 s), zurück nach oben nach 6 Erfolgen in Folge (ca. 60 s).
• In Stufe C bleibt das Raderbroich-LAN über den FRITZ!Box-Tunnel erreichbar, solange dieser die FRITZ!Box noch erreicht.
• Wichtig: In Stufe C läuft der Verkehr des Chalets ohne VPN über Huawei/Landal und erscheint dort mit der Adresse des Mobilfunk- bzw. Landal-Anschlusses.
• Zustand: cat /tmp/tunnel-failover.state, Log: logread -e tunnel-failover. Probelauf ohne Änderungen: DRY=1 /usr/sbin/tunnel-failover.
• Die Schnittstelle pve ist in der Firewall-Zone wireguard (NAT und Weiterleitung wie fritzbox).

Getestet am 10.10.2026: Ausgehenden FRITZ!Box-Tunnel (UDP 55536) blockiert → nach 37 s Stufe C, Internet direkt über Landal (19 ms); Block entfernt → nach ca. 70 s zurück in Stufe A. Stufe B ist noch nicht getestet, weil die Portfreigabe für den Server (UDP 51820) noch nicht wirkt.

Hinweis: Das Raderbroich-LAN erreicht Arcen (z. B. HA Raderbroich → HA Arcen) weiterhin nur über die FRITZ!Box.

Auf dem Sat-Client (10.10.12.220) stehen ganz oben (nach „FRITZ!Box Kabel (TV)“) neue Bouquets mit nur unverschlüsselten, deutschsprachigen Sendern. Quelle: Senderdatenbank des Sat-Servers (lamedb5, Sender mit CA-Kennung wurden entfernt) und die FRITZ!Box-Kabelsender. Sender, die es per Sat gibt, kommen vom Sat-Server (kein VPN-Verkehr); FRITZ!Box-Sender nur, wenn es sie nicht per Sat gibt.

• Die älteren Bouquets (dbe00 … dbe73, Sky usw.) bleiben unverändert. Vorherige bouquets.tv: /home/root/backup-20261010/bouquets.tv.vor-frei-bouquets.
• Nicht mehr enthalten, weil verschlüsselt: ORF1/ORF2 HD, PULS 4, ServusTV HD, Deluxe Music HD, die HD-Fassungen von RTL, SAT.1, ProSieben, VOX, kabel eins.
• Die Zuordnung der Themen läuft über Sendernamen (Schlüsselwörter), einzelne Sender können falsch eingeordnet sein. Bei Änderungen an der Senderliste des Sat-Servers müssen die Bouquets neu erzeugt werden.

Auf dem Dashboard dashboard-home (Ansicht „Home“, Abschnitt „Internet“) gibt es zwei neue Karten:

• VPN-Status: zeigt, ob und welcher Tunnel aktiv ist: VPN: FRITZ!Box (normal), VPN: Ersatz über Proxmox oder Kein VPN, direkt im Internet, dazu Zeitpunkt des Wechsels und den Zustand beider Tunnel. Quelle: Der Dienst tunnel-failover meldet per Webhook (Adresse in /etc/tunnel-hook) bei jedem Wechsel und alle 5 Minuten an HA. Helfer input_select.router_tunnel und input_text.router_tunnel_info, Automation „System: Router-Tunnel übernehmen“.
• Uplinks jetzt testen: Skript script.uplink_test_starten ruft http://10.10.11.1/cgi-bin/uplink-test auf (nur von 10.10.11.12). Auf dem Router misst /usr/sbin/uplink-test-run beide Uplinks direkt (je 2 × 1 MB und Ping, ca. 40 s, kostet ca. 2 MB Huawei-Volumen) und meldet das Ergebnis über den bestehenden Uplink-Webhook; die Karte „Internet“ zeigt Landal- und Huawei-Wert sowie die Empfehlung.

Messung am 10.10.2026 13:15: Landal 6,8 bis 18 Mbit/s (Ø 12,7), Ping Ø 165 ms (bis 562 ms); Huawei 6,6 bis 11,1 Mbit/s (Ø 9,4), Ping Ø 46 ms. Landal ist im Durchsatz mal besser, aber deutlich unruhiger.

• Problem: Der Knopf „Uplinks jetzt testen“ zeigte nur an. Der Watchdog entschied weiter nach seiner eigenen kleinen Messung (300 kB, alle 15 Minuten) und blieb deshalb teils auf dem Huawei, obwohl der Test Landal als deutlich schneller zeigte.
• Jetzt: /usr/sbin/uplink-test-run (je Uplink 2 × 1 MB und Ping) schreibt das Ergebnis nach /tmp/uplink-test.pref; uplink-watchdog (Fassung 5, Vorgänger /root/backup-20261010/uplink-watchdog.v4) übernimmt es sofort. Wer um mindestens 10 % schneller ist, wird bevorzugt, sonst bleibt der bisherige. In den folgenden 30 Minuten macht der Router keine eigene Messung. Das gilt im Modus Auto; bei fester Vorgabe (Huawei/Landal) wird nur angezeigt.
• Anzeige: Die Karte „Internet“ in HA Arcen nennt jetzt Messwerte, Grund (z. B. „Landal schneller (Test 14:03: …)“) und den Modus (Auto/Huawei/Landal). Die Auswahl darunter heißt „Modus: Auto = Router wählt den besseren Uplink“.
• Hinweis: Nach jedem Neustart des Dienstes misst der Watchdog nach ca. 30 s einmal selbst und kann dadurch kurz auf den anderen Uplink wechseln.

Änderung 10.10.2026: Der Abschnitt „Internet“ im Dashboard von HA Arcen (Uplink-Anzeige, Modus-Auswahl, VPN-Status, Knopf „Uplinks jetzt testen“) steht jetzt in der Ansicht „Übersicht“ (dashboard-home/ubersicht, zwischen „Sat-Receiver“ und „Störungsprotokoll“), nicht mehr auf „Home“.

• Befund: Nach dem Update auf 25.12.5 lief der Landal-Client wieder mit VHT 80 MHz (VHT-MCS 6 bis 9) und hatte sehr viele Sendefehler (tx failed ca. 30 %), die Messwerte schwankten stark (2 bis 18 Mbit/s). Die Anpassung in /lib/netifd/hostapd.sh (siehe oben) wird unter 25.12 nicht mehr benutzt: Die Client-Konfiguration entsteht jetzt im ucode-Modul /usr/share/ucode/wifi/supplicant.uc (Ausgabe in /var/run/wpa-supplicant-phy1-sta0.conf).
• Änderung: In supplicant.uc (Funktion setup_sta, nach config.scan_ssid = 1;) wird für das Netz „Free WiFi Landal“ disable_vht = true gesetzt. Original: /root/backup-20261010/supplicant.uc.orig.
• Ergebnis: In wpa-supplicant-phy1-sta0.conf steht disable_vht=1, der Client läuft wieder mit HT, 40 MHz, MCS 14/15 (270 Mbit/s), Sendefehler wieder niedrig, Ping ca. 17 ms ohne Verlust.
• Nach einem Firmware-Update: /usr/sbin/anpassungen-anwenden ausführen (trägt jetzt drei Stellen ein: hostapd.sh, netifd-wireless.sh, supplicant.uc), danach wifi down radio1; sleep 3; wifi up radio1. wifi reload reicht nicht, weil sich die UCI-Konfiguration nicht ändert.
• hostapd.sh-Zeile bleibt als Vorsorge stehen, hat unter 25.12 aber keine Wirkung.

• Die Aussage weiter oben („Sendefehler wieder niedrig, Ping ca. 17 ms“) hat sich nicht bestätigt: Die Quote nicht übertragener Pakete liegt in HT wie in VHT bei 15 bis 30 %, der Durchsatz schwankt zwischen 5 und 46 Mbit/s. Ein sauberer Vergleich HT gegen VHT (3 Runden) ergab im Mittel VHT ca. 27 Mbit/s, HT ca. 14 Mbit/s.
• Unter 25.12 verbindet sich der Client auch ohne die Anpassung mit dem starken Zugangspunkt. Der HT-Zwang ist dort vermutlich nicht mehr nötig. Er bleibt vorläufig aktiv; die Entscheidung steht aus.
• Ausführliche Erklärung mit Hintergrund zu HT/VHT/HE, den Messungen und den Optionen: Landal-WLAN: was umgebaut wurde, was VHT bedeutet und warum.
• Neues Backup mit diesen Dateien: Sicherungen, Generation 3.
• Zur Diagnose installiert und entfernbar: tcpdump, wpa-cli.

• Landal-WLAN: Die Anpassung (HT erzwingen) wurde zurückgenommen, der Client läuft mit VHT (Standard von OpenWrt 25.12.5). Begründung und Messwerte: Landal-WLAN: was umgebaut wurde, was VHT bedeutet und warum. Die älteren Abschnitte zur Anpassung weiter oben (hostapd.sh, supplicant.uc) beschreiben den Stand bis 17:40 Uhr.
• anpassungen-anwenden trägt nur noch die WLAN-Isolation (netifd-wireless.sh) ein.
• Aufgeräumt: DNS-Protokollierung (logqueries) aus, tcpdump entfernt. wpa-cli bleibt installiert (kleines Werkzeug, z. B. für wpa_cli -i phy1-sta0 status).
• Die Bresser-Wetterstation (7002580) ist vorerst nicht eingebunden (Station nicht im Chalet-WLAN).

Quelltexte und Erklärung aller Eigenbau-Skripte (Uplink-Watchdog, Tunnel-Failover, Uplink-Test, Landal-Vergleich und -Auswertung, Anpassungen nach Update): openwrtone_skripte