← Heimnetz-Übersicht · Router openwrtone · Netzwerk · Sicherungen

Stand: 10.10.2026, 17:20 Uhr. Diese Seite erklärt für Nicht-WLAN-Fachleute, was am Landal-Zugang des Routers verändert wurde. Sie enthält auch die Messergebnisse, einschließlich der Punkte, bei denen meine frühere Einschätzung nicht stimmte.

• Der Router in Arcen verbindet sich per WLAN-Client mit dem Park-WLAN „Free WiFi Landal“ (5 GHz). Das ist die zweite Internetleitung neben dem Huawei-Hotspot.
• Unter der alten Firmware (OpenWrt 24.10.0) brach die Verbindung zum nächsten, starken Zugangspunkt ständig ab, weil Router und Zugangspunkt sich über die WLAN-Betriebsart („HE“ gegen „VHT“) nicht einig wurden. Der Router nahm dann einen weit entfernten Zugangspunkt und kam nur auf ca. 0,8 Mbit/s.
• Die Lösung: Dem Router verbieten, die Betriebsart „VHT“ (und damit „HE“) zu benutzen. Er meldet sich dann als einfacher „HT“-Client (WLAN-Standard 802.11n) an. Damit klappte die Verbindung zum starken Zugangspunkt, gemessen wurden 20 bis 40 Mbit/s.
• Unter der neuen Firmware (25.12.5) steht diese Einstellung an anderer Stelle. Die alte Zeile wirkte nicht mehr und wurde neu eingetragen.
• Wichtig und ehrlich: Unter 25.12 verbindet sich der Client auch mit VHT problemlos mit dem starken Zugangspunkt. Der ursprüngliche Fehler tritt dort offenbar nicht mehr auf. Der HT-Zwang ist unter 25.12 daher vielleicht gar nicht mehr nötig. In einem Vergleichstest war VHT sogar im Durchschnitt schneller (siehe unten).

WLAN ist eine Reihe von Standards. Jede neue Generation kann „schneller sprechen“, aber beide Seiten müssen sie beherrschen und sich für eine gemeinsame Sprache entscheiden.

Zum Lesen der Zahlen im Router:

• Kanalbreite (MHz): Wie „breit die Straße“ ist. Doppelt so breit heißt grob doppelt so viel Daten, aber auch mehr Störungen und mehr Nachbarn, die sich überlappen.
• MCS („Modulation and Coding Scheme“): Ein Index, wie dicht die Daten gepackt werden. Je höher, desto schneller, aber desto empfindlicher gegen Störungen. Der Router wählt ihn selbst nach Signalqualität.
• NSS / Streams: Wie viele Datenströme gleichzeitig laufen (Antennen).
• Beispiele aus unserem Router: „MCS 15, 40 MHz“ (HT) entspricht ca. 270 bis 300 Mbit/s Verbindungsrate. „VHT-MCS 9, 80 MHz, 2 Streams“ entspricht ca. 866 Mbit/s.
• Wichtig: Das ist die Verbindungsrate zwischen Router und Zugangspunkt, nicht die Internetgeschwindigkeit. Netto bleiben etwa die Hälfte davon, geteilt mit allen anderen Gästen. Der Internetanschluss des Parks und die Auslastung am Abend begrenzen weit stärker als die WLAN-Betriebsart.

1. Der Zugangspunkt (AP) sendet ständig „Ich kann HT, VHT und HE“.
2. Der Client (unser Router) meldet sich an und nennt seine Fähigkeiten.
3. Der AP bestätigt, welche Betriebsart für diese Verbindung gilt.
4. Der Treiber im Router prüft, ob die Bestätigung zu dem passt, was der AP vorher angekündigt hat.

Bei Landal passte das nicht zusammen: Der AP kündigte HE (Wi-Fi 6) an, bestätigte aber nur VHT (Wi-Fi 5). Der Treiber des Routers (mt76/mac80211 auf dem MediaTek MT7981) wertete das als Fehler und brach die Verbindung ab. Das Log zeigte: AP appears to change mode (expected HE, found VHT), disconnect. Ein Vergleich: Auf dem Schild vor der Tür steht „Wir sprechen Deutsch und Französisch“, drinnen antwortet man nur auf Französisch, und der strenge Dolmetscher bricht das Gespräch ab.

• Der nächstgelegene Landal-AP (3C:46:A1:BE:A5:B0, Kanal 116, Signal ca. −46 dBm) lehnte die Verbindung wegen des HE/VHT-Fehlers ab. Der Router nahm einen weit entfernten AP (−79 dBm). Ergebnis: ca. 0,8 Mbit/s, Ping um 600 ms.
• Verschlüsselungs- und Cipher-Einstellungen änderten nichts. Auch ein anderes WLAN-Paket (wpad-mbedtls) hätte nichts gebracht, es kennt keine Option „HE für Clients aus“.
• Die Änderung: In /lib/netifd/hostapd.sh wurde für das Netz „Free WiFi Landal“ disable_vht=1 ergänzt. Der Router tritt dann als reiner HT-Client auf, ohne VHT und damit auch ohne HE (HE baut im 5-GHz-Band auf VHT auf).
• Ergebnis gestern: Verbindung zum starken AP, HT mit 40 MHz, 270 Mbit/s Verbindungsrate, gemessen 20 bis 40 Mbit/s, kein Paketverlust, Ping ca. 20 ms. Das war eine echte Verbesserung gegenüber 0,8 Mbit/s.

• Befund nach dem Update: Die Zeile in hostapd.sh wirkt nicht mehr, denn 25.12 erzeugt die WLAN-Client-Konfiguration in einem anderen Modul: /usr/share/ucode/wifi/supplicant.uc (ausgegeben in /var/run/wpa-supplicant-phy1-sta0.conf).
• Änderung: In supplicant.uc (Funktion setup_sta) wird für „Free WiFi Landal“ disable_vht = true gesetzt. In der erzeugten Konfiguration steht dann disable_vht=1. Das Original liegt als /root/backup-20261010/supplicant.uc.orig.
• Aktivieren geht nur über einen Neustart des Funkteils: wifi down radio1; sleep 3; wifi up radio1. (wifi reload reicht nicht, weil sich in der UCI-Konfiguration nichts ändert.)
• Nach jedem Firmware-Update geht die Änderung verloren: /usr/sbin/anpassungen-anwenden ausführen, danach Funkteil neu starten.

Messung direkt über die Landal-Schnittstelle (am Tunnel vorbei), je Runde 3 × 3 MB und 10 Pings. Im Wechsel HT (VHT abgeschaltet) und VHT (angeschaltet), 3 Runden, alles im selben Zeitraum:

Ergebnis:

• Durchsatz: VHT im Mittel ca. 27 Mbit/s, HT ca. 14 Mbit/s (in 2 von 3 Runden war VHT deutlich schneller).
• Sendefehler (Pakete, die auch nach Wiederholungen nicht ankamen): HT ca. 15 %, VHT ca. 23 %. Mit beiden Modi sind 15 bis 30 % ungewöhnlich hoch.
• Ping: in beiden Modi ähnlich (20 bis 30 ms im Mittel), mit gelegentlichen Ausreißern bis 120 ms.

Was daraus folgt:

• Der HT-Zwang ist unter 25.12 kein klarer Gewinn. Meine frühere Aussage nach dem Neustart des Funkteils („Sendefehler wieder niedrig“) war zu früh und stimmte nicht: Die Quote lag auch in HT bei 15 bis 30 %.
• Vermutete Ursache der hohen Fehlerquote: Die Auslastung des Park-WLANs am Samstagabend (viele Gäste) oder der Zugangspunkt selbst. Das ist nicht bewiesen, denn auch in VHT ist die Quote hoch.
• Die Messwerte schwanken von Minute zu Minute stark (5 bis 46 Mbit/s). Drei Runden sind eine Momentaufnahme.

Mein Vorschlag: Einen Tag lang beobachten (Karte „Internet“ in Home Assistant) und danach entscheiden. Umschalten geht in einer Minute:

• Nur ausprobieren, bis zum nächsten Neustart des Funkteils:

wpa_cli -p /var/run/wpa_supplicant -i phy1-sta0 set_network 2 disable_vht 0   # VHT erlauben
wpa_cli -p /var/run/wpa_supplicant -i phy1-sta0 set_network 2 disable_vht 1   # HT erzwingen
wpa_cli -p /var/run/wpa_supplicant -i phy1-sta0 reassociate

• Dauerhaft VHT: cp /root/backup-20261010/supplicant.uc.orig /usr/share/ucode/wifi/supplicant.uc; wifi down radio1; sleep 3; wifi up radio1. Auch die Zeile in /usr/sbin/anpassungen-anwenden (Block 3) müsste entfernt werden, sonst wird sie nach dem nächsten Update wieder gesetzt.

iw dev phy1-sta0 link              # "MCS ... 40MHz" = HT, "VHT-MCS ... 80MHz" = VHT
iw dev phy1-sta0 station dump      # tx failed / tx packets = Sendefehlerquote
landal-test                        # Zugangspunkt, Signal, 3 Messungen, Paketverlust (3 MB)
grep disable_vht /var/run/wpa-supplicant-phy1-sta0.conf   # steht dort disable_vht=1, ist HT erzwungen

Sicherung der Router-Konfiguration samt dieser Dateien: Sicherungen, Generation 3 „Landal-Anpassung“.

Weitere Hintergründe: Router openwrtone (Abschnitt „Landal: naher Zugangspunkt funktioniert“ und Nachträge vom 10.10.2026).

• Beschluss: Nach dem Vergleich (VHT im Mittel ca. 27, HT ca. 14 Mbit/s) und weil der ursprüngliche HE/VHT-Fehler unter OpenWrt 25.12.5 nicht mehr auftritt, läuft der Landal-Client wieder mit der Standardeinstellung (VHT).
• Zurückgenommen:
  • /usr/share/ucode/wifi/supplicant.uc aus /root/backup-20261010/supplicant.uc.orig wiederhergestellt (enthält kein disable_vht mehr).
  • /lib/netifd/hostapd.sh aus hostapd.sh.orig-vor-anpassung wiederhergestellt.
  • /usr/sbin/anpassungen-anwenden trägt nur noch die WLAN-Isolation (netifd-wireless.sh) ein, nicht mehr die Landal-Zeilen. Vorherige Fassung: /root/backup-20261010/anpassungen-anwenden.vor-vht-umstellung.
  • Funkteil neu gestartet (wifi down radio1; wifi up radio1).
• Ergebnis direkt danach: Verbindung zum starken Zugangspunkt, VHT-MCS 4, 80 MHz, 2 Streams (351 Mbit/s), Ping ca. 20 ms ohne Verlust.
• Wenn der Abbruch („expected HE, found VHT“) bei Landal wieder auftritt: Der Watchdog wechselt dann automatisch auf den Huawei. Die Anpassung lässt sich in einer Minute zurückholen, siehe Abschnitt „Entscheidung: HT lassen oder VHT erlauben?“ (Befehle mit wpa_cli oder Einsetzen der Zeilen in supplicant.uc).
• Sicherung: Generation 3 „Landal-Anpassung“ (siehe Sicherungen) enthält noch den Stand mit HT-Zwang. Dieser Stand ist damit auch die Vorlage, falls man ihn wieder braucht.

• Nach der Umstellung auf VHT (17:40 Uhr) war das Landal-WLAN laut Nutzer „wieder sehr langsam“. Auf Wunsch wurde der HT-Zwang wieder eingesetzt (disable_vht=1 in supplicant.uc, Funkteil neu gestartet, Skript anpassungen-anwenden mit den Landal-Zeilen zurück; die VHT-Fassung liegt als /root/backup-20261010/anpassungen-anwenden.vht-fassung).
• Messung direkt nach der Rückkehr (HT, 17:50 Uhr): 4, 5 und 8 Mbit/s, Ping ca. 18 ms, 0 % Verlust, Verbindungsrate MCS 11 bis 15 mit 40 MHz. Das Tempo war also auch in HT niedrig. Die Schwankungen kommen offenbar von der Auslastung des Park-WLANs (Abend) und nicht von der Betriebsart. Die Einschätzung „VHT ist im Mittel schneller“ bezieht sich auf den Vergleich von 17:09 bis 17:15 Uhr und ist eine Momentaufnahme.
• Aktueller Stand: HT erzwungen. Eine Entscheidung nach Tageszeit-unabhängiger Messreihe (z. B. morgens, mittags, abends je einmal HT/VHT) steht aus.

Damit die Entscheidung auf mehr als einer Momentaufnahme beruht, läuft jetzt dreimal täglich auf dem Router selbst (ohne Mac) ein Vergleich. Home Assistant Arcen zeigt die Ergebnisse an.

In Home Assistant Arcen (Ansicht „Übersicht“, Abschnitt „Internet“, ganz unten „Landal: HT gegen VHT“):

• Tabelle der letzten Messung (Durchsatz, Fehlerquote, Ping je Modus).
• Statistik je Modus über die letzten 21 Messungen (ca. 7 Tage): Mittelwerte und Mittel getrennt nach morgens, mittags, abends. Die Mittelwerte berechnet der Router, die Texte stehen in input_text.landal_statistik_ht und _vht.
• Zwei Verlaufsdiagramme (7 Tage): Durchsatz und Fehlerquote.
• Helfer: input_number.landal_{ht,vht}_{durchsatz,fehlerquote,ping}, input_text.landal_vergleich_info. Automation „System: Landal-Vergleich HT/VHT übernehmen“.

Auswertung: Nach ca. einer Woche (21 Messungen) zeigt die Statistik, welcher Modus im Mittel schneller ist und ob das zu bestimmten Tageszeiten anders ist. Erst dann würde ich die Betriebsart endgültig festlegen.

Erster brauchbarer Lauf (17:34 Uhr): HT 7,8 Mbit/s, Fehler 14 %, Ping 21 ms; VHT 11,7 Mbit/s, Fehler 22 %, Ping 20 ms.

Der Router openwrtone misst selbständig, ob der Landal-Client mit HT (802.11n) oder VHT (802.11ac) schneller und stabiler läuft. Er ist unabhängig vom MacBook.

Ablauf (Skript /usr/sbin/landal-vergleich)

• Start per Cron (07:45, 19:45 und 07:45/19:45-Raster 45 7/12/19) und stündlich durch Home Assistant Arcen, wenn die Alarmanlage scharf ist (CGI /www/cgi-bin/landal-vergleich?alarm=…, nur von 10.10.11.12 erlaubt).
• Läuft nur, wenn Landal verbunden und Huawei online ist. Vorher wird der Uplink auf Huawei gestellt, damit der Tunnel während der Messung stabil bleibt; danach wird der vorherige Modus (/tmp/uplink-mode) und der Grundzustand HT wiederhergestellt.
• Je Modus: Neuverbindung mit disable_vht 1 bzw. 0, 2 × 1 MB Download (Cloudflare) über phy1-sta0, 10 Pings, Zähler Sendepakete/-fehler. Die Reihenfolge wechselt, damit Reihenfolgeeffekte ausgeglichen werden.
• Ergebnis geht per Webhook an HA (Texte Landal Vergleich, Statistik gesamt/HT/VHT, Verlaufsgrafiken auf der Übersicht).

Daten

• /root/landal-vergleich.csv (Semikolon; max. 15000 Zeilen, Vorgängerdatei .alt; steht in /etc/sysupgrade.conf, übersteht also Updates).
• Spalten: epoch; datum; zeit; wochentag; stunde; tageszeit (nachts/morgens/mittags/abends); quelle (cron|ha); alarm; reihenfolge; bssid; freq_mhz; signal_dbm; uplink_vorher; je HT und VHT: mbit10 (Mbit/s × 10), dl1_kbs, dl2_kbs, fehler_pm (Promille), ping_avg, ping_max, pakete, fehler, rate_mbit; sowie ht_/vht_pingverlust_pct.

Auswertung

• Auf dem Router: landal-auswertung [Tage] – Gesamt, nach Tageszeit, Alarmstatus, Stunde und je Tag, inklusive Anteil „VHT schneller“.
• Empfehlung: etwa eine Woche sammeln, dann HT oder VHT endgültig festlegen. Bis dahin ist HT erzwungen.

Erste Messwerte: 18:27 HT 24,3 / VHT 0,3 Mbit/s (VHT brach ab); 18:29 HT 2,7 / VHT 24,5 Mbit/s. Die Landal-Leitung schwankt stark (5–46 Mbit/s), Einzelwerte sind daher wenig aussagekräftig.

Korrektur/Ergänzung: Die Cron-Messungen laufen um 07:45, 12:45 und 19:45 (nicht nur zweimal). Die vollständigen Quelltexte aller Skripte mit Erklärung stehen auf openwrtone_skripte.