wiki.no-br.de

Eine ältere Version des Dokuments wurde geladen! Beim Speichern wird eine neue Version des Dokuments mit diesem Inhalt erstellt.

====== Router openwrtone (Arcen) ======

[[:start|← Heimnetz-Übersicht]] · [[infrastruktur:netzwerk|Netzwerk Raderbroich und Arcen]] · [[ha:arcen:start|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.

===== Überblick =====

<mermaid>
%%raw
flowchart LR
 subgraph ARC["Chalet Arcen (NL)"]
 direction TB
 HW["Huawei E5577 192.168.8.1 SSID HUAWEI_E5577_E353"]
 LD["Free WiFi Landal Gateway 192.168.0.1"]
 OW["openwrtone OpenWrt One · 10.10.11.1"]
 LAN["LAN 10.10.11.0/24 HA Arcen .12 · WLAN-Geräte"]
 HW -. "Hauptleitung WLAN-Client phy0-sta0 (2,4 GHz)" .- OW
 LD -. "Ersatz WLAN-Client phy1-sta0 (5 GHz)" .- OW
 OW --- LAN
 end
 FB["FRITZ!Box 6591 Raderbroich"]
 OW <==>|"WireGuard 'fritzbox' gesamter Verkehr, UDP 55536"| FB
 FB --- NET(["Internet"])
</mermaid>

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.

===== Hardware und System =====

===== Anschlüsse und Schnittstellen =====

===== WLAN =====

^ Funkteil ^ Band ^ Kanal ^ Breite ^
| ''radio0'' | 2,4 GHz | eingestellt 6, läuft auf dem Kanal des Huawei (zuletzt 9) | HT20 |
| ''radio1'' | 5 GHz | ''auto'' (folgt dem Landal-Zugangspunkt) | HE80 |

''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.

==== Landal-Zugangspunkte (Scan 09.10.2026) ====

^ Signal ^ Kanal ^ BSSID ^ Bemerkung ^
| -47 dBm | 116 | ''3C:46:A1:BE:A5:B0'' | am stärksten, **Verbindung scheitert** (siehe unten) |
| -79 dBm | 124 | ''00:E6:3A:AF:3D:70'' | **wird derzeit genutzt** |
| -86 dBm | 116 | ''D0:4F:58:9A:0A:C0'' | |
| -86 dBm | 108 | ''A8:0B:FB:85:39:20'' | |

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''.

===== Routing =====

===== Umschaltung Huawei / Landal (uplink-watchdog) =====

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.

^ Eigenschaft ^ Wert ^
| Skript | ''/usr/sbin/uplink-watchdog'' |
| Dienst | ''/etc/init.d/uplink-watchdog'' (aktiviert, startet beim Booten, wird bei Absturz neu gestartet) |
| Prüfung | alle 10 s Ping über den Huawei an ''1.1.1.1'', ''8.8.8.8'', ''9.9.9.9'' (einer muss antworten) |
| Wechsel auf Landal | nach 3 Fehlversuchen in Folge (ca. 30 s), oder sofort, wenn die WLAN-Verbindung zum Huawei weg ist |
| Zurück auf Huawei | nach 6 Erfolgen in Folge (ca. 60 s) |
| MyFRITZ!-Adresse | wird alle 5 Minuten neu aufgelöst, der Tunnel-Endpunkt bei Änderung nachgezogen |
| Sysupgrade | beide Dateien stehen in ''/etc/sysupgrade.conf'' und bleiben bei einem Firmware-Update erhalten |

Zustand ansehen:

<code>
cat /tmp/uplink-watchdog.state
logread -e uplink-watchdog
</code>

''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.

===== WireGuard-Kopplung =====

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.

===== Firewall =====

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.

===== DHCP und DNS =====

Momentaufnahme der DHCP-Geräte (02.10.2026):

===== Zugang =====

* **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.

===== Umbau vom 09.10.2026 zurücknehmen =====

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

<code>
/root/umbau-rollback.sh now
</code>

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.

===== Offene Punkte und Auffälligkeiten =====

* **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.

===== Anzeige in Home Assistant Arcen =====

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.

===== Drossel-Erkennung: Huawei langsam, Landal schneller =====

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.

^ Eigenschaft ^ Wert ^
| Messung | alle 15 Minuten 100 kB über den Huawei, direkt am Tunnel vorbei (''curl --interface'') |
| Datenverbrauch | ca. 10 MB pro Tag auf dem Huawei |
| Schwelle | unter **40 kB/s** (ca. 0,3 Mbit/s) gilt der Huawei als gedrosselt, es wird ein zweites Mal gemessen |
| Vergleich | nur dann wird auch Landal gemessen; ist Landal mehr als 1,5-mal so schnell, läuft der Tunnel über Landal |
| Zurück | sobald der Huawei wieder mindestens 80 kB/s schafft oder Landal nicht mehr deutlich schneller ist |
| Einstellen | Variablen ''SPEED_EVERY'', ''SLOW_KBS'', ''SPEED_URL'' oben in ''/usr/sbin/uplink-watchdog'' |

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''.

==== Home Assistant ====

* ''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''.

===== Landal: naher Zugangspunkt funktioniert (Stand 09.10.2026, 17:05 Uhr) =====

**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.

===== Uplink-Regel seit 09.10.2026, 17:15 Uhr: der schnellere gewinnt =====

**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''.

==== Home Assistant ====

* ''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.

===== Netz 10.10.12.0/24 (zweiter Router, WLAN nb.tv) =====

''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.

===== Nachtrag 09.10.2026, 17:40 Uhr: nb.tv-Route und WLAN-Geräte untereinander =====

**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.

===== Zweiter Router nb.tv (10.10.12.1): Stand 09.10.2026, 17:50 Uhr =====

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''.

===== Sat-Receiver im Netz nb.tv und Home Assistant (10.10.2026) =====

^ Gerät ^ Adresse ^ Anschluss ^ Strom über ^
| **Sat-Server** – GigaBlue UHD IP 4K, OpenATV 7.6, hängt an der Schüssel | ''10.10.12.105'' (WLAN nb.tv) | streamt per Port 8001 an den Client | Steckdose „Sat-Server“ (''switch.hmip_arcen_steckdosesatserver'') |
| **Sat-Client** – GigaBlue UHD IP 4K, OpenATV 7.6, am Fernseher | ''10.10.12.220'' (Kabel am zweiten Router) | | Steckdose „Fernseher“ (''switch.hmip_arcen_dosefernseher''), **an derselben Steckdose hängt auch der zweite Router** |

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“.

===== Nachtrag 10.10.2026 =====

==== Uplink von Hand wählen (Home Assistant) ====

* 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''.

==== FRITZ!Box-Kabelfernsehen am Sat-Client ====

* 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/''.

==== Funkstrecke Sat-Server messen ====

* 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.

===== Update auf OpenWrt 25.12.5 (10.10.2026) =====

**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'').

^ Router | Vorgehen |
| nb.tv (10.10.12.1) | Standard-Image 25.12.5, Konfiguration erhalten, danach ''luci-proto-wireguard'' per apk nachinstalliert |
| openwrtone (10.10.11.1) | Image vom Imagebuilder (sysupgrade.openwrt.org) mit ''luci'', ''luci-ssl'', ''luci-proto-wireguard'', ''wireguard-tools'', ''kmod-wireguard'', ''luci-app-nlbwmon'', ''luci-app-vnstat2'', ''curl''; Konfiguration erhalten |

Sicherungen vor dem Update: [[infrastruktur:backup:start|Sicherungen]].

==== Eigene Anpassungen nach Updates ====

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''

==== Probleme beim Update und Lehren ====

* **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.

==== Tests nach dem Update (10.10.2026, 10:45 bis 10:48 Uhr) ====

* **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.

===== Sicherungen (Stand 10.10.2026) =====

Alle Archive sind verschlüsselt, Details und Prüfsummen auf [[infrastruktur:backup:start|Sicherungen]].

^ Gerät ^ Konfiguration ^ Eigene Anpassungen ^
| openwrtone (10.10.11.1) | {{:infrastruktur:backup:20261010:openwrtone-config-20261010.verschluesselt.gz|openwrtone-config}} | {{:infrastruktur:backup:20261010:openwrtone-custom-20261010.verschluesselt.gz|openwrtone-custom}} |
| Router nb.tv (10.10.12.1) | {{:infrastruktur:backup:20261010:router2-config-20261010.verschluesselt.gz|router2-config}} | {{:infrastruktur:backup:20261010:router2-custom-20261010.verschluesselt.gz|router2-custom}} |
| Sat-Server (10.10.12.105) | {{:infrastruktur:backup:20261010:sat-server-config-20261010.verschluesselt.gz|sat-server-config}} | – |
| Sat-Client (10.10.12.220) | {{:infrastruktur:backup:20261010:sat-client-config-20261010.verschluesselt.gz|sat-client-config}} | – |

===== Tunnel-Umschaltung mit drei Stufen (seit 10.10.2026) =====

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.

===== Sat-Client: Bouquets „Frei DE“ (10.10.2026) =====

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.

===== Anzeige „VPN“ und Knopf „Uplinks jetzt testen“ in HA Arcen (10.10.2026) =====

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.

==== Nachtrag 10.10.2026, 14:05 Uhr: Testergebnis wird übernommen ====

* **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“.

==== Nachtrag 10.10.2026, 16:20 Uhr: Landal-Anpassung unter 25.12 nachgezogen ====

* **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.

==== Korrektur 10.10.2026, 17:20 Uhr: Landal unter 25.12 ====

* 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: [[infrastruktur:landal_wlan|Landal-WLAN: was umgebaut wurde, was VHT bedeutet und warum]].
  * Neues Backup mit diesen Dateien: [[infrastruktur:backup:start|Sicherungen]], Generation 3.
  * Zur Diagnose installiert und entfernbar: ''tcpdump'', ''wpa-cli''.

==== Nachtrag 10.10.2026, 17:40 Uhr: VHT erlaubt, Aufräumen ====

* **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: [[infrastruktur:landal_wlan|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): [[infrastruktur:openwrtone_skripte]]

Zusammenfassung