[Amazon.de, auch fr/it/es] Zyxel Multy M1 AX1800 (WSM20, 3er-Pack) [OpenWRT; kein DSL-Modem; WiFi; Router; Gigabit Ethernet]

Also ich komme auf absehbare Zeit nicht dazu, die Geräte ernsthaft einzusetzen, aber natürlich habe ich mir einen kleinen Einblick gegönnt, um zu sehen, was mich erwartet - und auch ein bisschen herumgespielt. Von vorne:

***HINWEIS***: Der Text ist etwas umfangreicher geworden und hat sich spontan zu einer kleinen Begleitung auf meiner Reise mit den Geräten bis hier und jetzt entwickelt. Ich bitte abschweifende Momente (auch zu Dokumentationszwecken für mich) zu entschuldigen.

***Lieferung / Unboxing***
Die Geräte kamen in einem Dreier-Karton, der wiederum ein Zweier-Paket und ein Einzel-Paket beinhaltet. Die Angabe des Zweier-Pakets, es seien zwei Ethernet-Kabel beinhaltet, ist überklebt mit der Angabe, dass ein Ethernet-Kabel beinhaltet ist - was so auch korrekt ist. In Summe sind es also zwei.

***Ersteinrichtung / Installation OpenWRT***
Ich habe die Geräte (natürlich) nicht mit der Cloud bekannt gemacht, sondern mich beim ersten Gerät gleich an die Installation von OpenWRT gemacht. Hat im Grunde geklappt, wie bei OpenWRT beschrieben; ich habe allerdings verschiedene Browser dafür versucht.

Im privaten Modus im Firefox wollte das nicht klappen, war am Ende im normalen Modus im Edge dann möglich. Gefühlt merkt sich der Router die Session und "sperrt", wenn man "on the fly" den Browser wechselt. Ich meine, das LAN-Kabel einmal zu trennen und wieder zu verbinden hat dann geholfen - also die Netzwerkverbindung einmal neu aufbauen. Kann aber an meinem Rechner (Windows 10 N) auch sehr nischiges Phänomen sein.

Jedenfalls wird (grob gesagt) das erste Image ja per Web-UI hochgeladen, nach dessen Boot schaltet man sich per ssh auf den Router und zieht dann das zweite Image wahlweise über das Internet auf den Router oder pumpt es vom lokalen Rechner (nach Download dorthin) in den Router. Ich wollte den gesamten Vorgang offline vornehmen und habe mich so für zweiteres (via scp) entschieden - an sich alles komplett problemlos nach Anleitung.

Jetzt oute ich mich mal als "praktischer Newbie" - ich weiß zwar, was da grob passiert, hatte das in der Praxis aber noch nie getan. Beim Verbindungsaufbau per ssh (unter Windows per cmd oder Powershell) war ich zunächst etwas überrascht dass das Gerät "permanent" als vertrauenswürdig hinterlegt werden soll und ohne Mitgabe eines Benutzers mMn. nicht nochmal gefragt wurde, welchen Benutzer man gebrauchen möchte. Zwei Dinge dazu:

* Ding Nummer eins: Der vertrauenswürdige ssh-Host wird in C:\Benutzer\<Benutzername>\.ssh\known_hosts hinterlegt. Damit kann man nun anfangen, was man will (beibehalten oder wieder entfernen, sodass man beim nächsten Mal wieder gefragt wird). Das kann insbesondere dann relevant werden, wenn man den Router mal zurücksetzt und er dann eine andere ID hat.
* Ding Nummer zwei: Der (korrekte) Benutzer kann z.B. über "ssh root@192.168.1.1" mitgegeben werden. Dann klappt auch die Anmeldung.

Anschließend habe ich mir mit den ersten Videos dieser Tutorial-Reihe ganz praktisch in der Web-Oberfläche einen kleinen Überblick verschafft. Das fand ich soweit ganz kurzweilig. Zwei Hinweise auch dazu:

* Hinweis Nummer eins: Ich habe in den Softwarepaketen keine zusätzlichen Treiber finden können. Das ergibt auch vollständig Sinn, denn die zum Download angebotenen Images für den Router hier (WSM20) sind ja genau für diesen zusammengestellt.
* Hinweis Nummer zwei: Ich hatte beim Durchsuchen der Repositories nach einigen mMn. passenden Buzzwords ein Paket namens "luci-app-advanced-reboot" gefunden. Der Router ist lt. Installationsseite (sh. Installation erstes Image) ein Gerät mit "dual firmware", wird von diesem Paket (für "dual-partition routers") aber nicht automatisch unterstützt. Ich weiß nicht, ob "dual firmware" immer und überall mit "dual-partition" umgesetzt wird oder ich hier gerade ggf. auf der einen Seite Äpfel und auf der anderen Seite Birnen habe, aber möglich wär's ja. Die Unterstützung manuell herzustellen, habe ich noch nicht probiert. Was ich aber sagen kann, ist: Die "Herunterfahren"-Funktion, die das Paket dann über die eigene Oberfläche (im Menü "System" erreichbar) anbietet, scheint zu funktionieren. Jedenfalls geht nach kurzer Zeit die LED am Router einfach aus.

***Erster Eindruck (gilt erstmal OpenWRT, nicht dem Gerät)***
Auf mich wirkt die Oberfläche recht sauber. Es gibt allerdings auch massig Optionen, gefühlt werde ich noch recht viel Zeit investieren (müssen). Die Darreichungsform ist für mich (muss nichts heißen) gut verträglich und deutlich anders als insbesondere bei MikroTiks RouterOS, das aber auch eine andere Zielgruppe haben dürfte.

Für mich ein auffälliges Beispiel: bei RouterOS kann ich mir z.B. die unterstützten Bandbreiten im WiFi explizit über Checkboxen zu einer individuellen Auswahl über die GUI einstellen. Bei OpenWRT kann ich "nur" fertige Bündel über die "Coverage cell density" auswählen - diese ergeben aber auch absolut Sinn. Wer damit nichts anfangen kann - kein Problem, das ist auch eher ein Spezialfall der Spezialfälle und nichts, was man zuhause oder grundsätzlich benötigen würde, hatte ich nur zu Diagnosezwecken mal genutzt...

Worauf ich damit hinaus möchte: RouterOS bietet einige Dinge an, die OpenWRT nicht anbietet. Ich habe gelesen, dass es an manchen Stellen ggf. umgekehrt sei, was ich aktuell nicht beurteilen kann. Nichtsdestotrotz hat man in beiden Fällen (OpenWRT und RouterOS) die Möglichkeit, auf das Terminal durchzugreifen und somit auch abseits der GUI exotischere Konfigurationen vorzunehmen. Ich gehe davon aus, dass sich die Konfigurationsmöglichkeiten so nicht wirklich etwas nehmen. Angenehmer bedienen lässt sich bislang OpenWRT. Es wirkt auf mich um einiges klarer und übersichtlicher, wenngleich etwas verspielter, als das bei RouterOS der Fall ist - aber keinesfalls unseriös.

***Erster Geräteeindruck***
Die Geräte kommen schlicht daher, für meinen Geschmack auch recht kompakt. Wartezeiten in Luci (der Oberfläche OpenWRTs) sind überschaubar, das Arbeitstempo für meine Begriffe völlig ok. Einen direkten Vergleich zu anderen Geräten mit OpenWRT habe ich allerdings auch nicht, nur andere Router diverser Hersteller. Den LED-Knopf zum abschalten der Status-LED des Gerätes habe ich im Auslieferungszustand dieses ersten Gerätes nicht ausprobiert - unter OpenWRT scheint er jedenfalls funktionslos zu sein. Grundsätzlich bringt OpenWRT eine LED-Konfiguration mit und an den Knopf kommt man bestimmt auch noch irgendwie ran - ob man die Funktion ggf. wiederherstellen kann, habe ich nicht probiert.

*** *** Vorbereitung auf diesen Post *** ***

***DFS***
Tatsächlich scheint DFS (siehe Dealbeschreibung) hier mit OpenWRT vorhanden zu sein - man kann damit mehr WiFi6-Kanäle wählen, als es (wie im Deal verlinkt) unter der Herstellersoftware möglich zu sein scheint. Das ist großartig!
Jedenfalls habe ich mich mal von hinten (Kanal 173) an die DFS-Kanäle (ab 144 abwärts) herangerobbt (siehe hierzu auch Wikipedia zu DFS in der EU). Auszug aus dem System-Log (Datum / Zeit nicht synchronisiert, nicht wundern...):

Kanal 173 (5865 MHz, Breite testweise 20 MHz):
>> Thu Nov 9 01:29:57 2023 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->ENABLED
>> Thu Nov 9 01:29:57 2023 daemon.notice hostapd: phy1-ap0: AP-ENABLED
>> Thu Nov 9 01:29:57 2023 daemon.notice netifd: Wireless device 'radio1' is now up

entsprechender Abschnitt mit Kanal 140 (5700 MHz, Breite testweise 20 MHz):
>> Thu Nov 9 01:37:05 2023 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->DFS
>> Thu Nov 9 01:37:05 2023 daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5700 chan=140 sec_chan=0, width=0, seg0=0, seg1=0, cac_time=60s
>> Thu Nov 9 01:37:06 2023 daemon.notice netifd: Wireless device 'radio1' is now up

(!!!)Ganz wichtig(!!!) dürfte an dieser Stelle aber sein, dass man in den erweiterten Einstellung des WiFis den korrekten Ländercode hinterlegt, damit die lokal anzuwendenden Regeln in den jeweiligen Frequenzbändern angezogen werden können. Daher vmtl. auch die Zeile mit "COUNTRY_UPDATE", um das zu prüfen. Hoffentlich sind sie korrekt implementiert, aber der erste Versuch sah erstmal gut aus.

Da ich außerdem nicht weiß, wie sich die OpenWRT-Installation auf diesem Gerät verhält, wenn dann doch mal ein Signal detektiert wird und der Kanal aufgegeben werden muss (Ausweichen? Deaktivieren?), werde ich die betroffenen Kanäle vmtl. erstmal meiden. Aber es ist gut zu wissen, dass alles an Bord ist und die Hardware mindestens im Zweifelsfall auch hier umfangreicher genutzt werden kann, als im Auslieferungszustand.

(Randnotiz: Bzgl. der "oberen" Kanäle hatte ich mich zunächst schon gewundert, viel später dann eine Erklärung hier gefunden.)

***Vorbereitung Durchsatzmessung***
Gerne wollte ich außerdem den Datendurchsatz messen (bzw. grob bestimmen), um mal ein Gefühl zu bekommen. Das Verfahren habe ich mir erstmal grob erarbeitet und nur vergleichsweise schlechte Hardware am Start - man möge mir Fehler und Unsauberkeiten bitte nachsehen. Am Start sind also: Ein Haswell-Pentium aus 2013 am Gigabit-LAN und ein Trekstor Surfbook am WiFi5(!), also 802.11ac mit stets 433 Mbit/s sowie jeweils iperf 2.1.9 (bezogen von hier).

Interessante Punkte im Vorbeigehen, die mit dem Deal nicht viel zu tun haben:
- Windows 10 antwortet in Standardeinstellungen nicht auf Pings. (Erleuchtung kam von hier.)
- iperf braucht auf Server-Seite im Standard eine eingehende Firewall-Regel für TCP/5001
- um es nicht unerwähnt zu lassen / die Nachvollziehbarkeit zu verbessern: um die IP-Adresse des aktuellen Gerätes herauszufinden, nutze ich i.d.R. ipconfig. Mich durch die Oberflächen zu klicken, ist mir meistens zu mühsam.

Was mit dem Deal wieder zu tun hat: Während der Vorbereitung (Fehlersuche / -Behebung im Verbindungsaufbau) habe ich mich einmal aus der Router ausgesperrt. Das hat mich zu einer weiteren Erkenntnis geführt: Der Reset-Knopf funktioniert wie gewünscht. Losgelassen habe ich, als die LED schnell rot blinkte. Hinterher war der Router wie erwartet zurückgesetzt.

So ging's dann weiter:

***Durchsatzmessung***
Mein Vorgehen:
- Geräte jeweils verbinden,
- Firewallregel (als Administrator) auf Server-Seite (für mich: Rechner am Gigabit Ethernet) anlegen,
-> netsh advfirewall firewall add rule name= "Open Port 5001 TI" dir=in action=allow protocol=TCP localport=5001
- Software (als Benutzer) als Server starten,
-> iperf.exe -s
- Software jeweils (als Benutzer) als Client starten,
-> iperf.exe -c <ServerIP>
- Server beenden,
- Firewallregel (als Aministrator) auf Server-Seite wieder rausnehmen,
-> netsh advfirewall firewall delete rule name= "Open Port 5001 TI" dir=in protocol=TCP localport=5001
- auswerten.

Was kam nun raus?
Wie beschrieben, die Verbindung wurde mit 433 Mbit/s in beide Richtungen (Up-/Download) aufgebaut.
Keinen Meter vom Router weg (aber hinter einem weiteren Bildschirm versteckt), bleiben in der iperf-Praxis noch 260-270 Mbit/s übrig. (#1)
Eine Trockenbau- und eine Mauerwand sowie ca. sieben Meter vom Router entfernt, waren noch 140-150 Mbit/s da. (#2)
Eine weitere Mauerwand und ein weiterer Meter (plus ungünstigere Position - da war ungefähr der Schacht für und mit den Wasserleitungen zwischen) waren es dann noch 100 - 110 Mbit/s. (#3)
Nach einer weiteren Wand und (also 1x Trockenbau, 3x gemauert) und weiteren eineinhalb Metern (in Summe also etwa neuneinhalb) wurde es mit ca. fünf bis zehn Mbit/s dann sehr dünn. (#4)

Nun hilft das ja so vmtl. niemandem richtig weiter. Als einziges Vergleichsobjekt habe ich hier noch meinen Gigacube (von dort). Mit dem habe ich schnell noch eine Runde gemessen, allerdings nur das erste und das dritte Szenario.
Ergebnisse hier: 190 - 280 Mbit/s (#1, streut exorbitant) und 15 - 25 Mbit/s (#3).

Tendenziell erscheint mir der ZyXEL-Router damit schon einmal deutlich leistungsfähiger, als der Gigacube.
Der Gigacube war "nur" auf 802.11ac, Kanal 36, 80 MHz Breite konfiguriert, der ZyXEL WSM20 auf 802.11ax, Kanal 44, 80 MHz Breite; beide arbeiteten damit mWn. und lt. WiFiAnalyzer im gleichen (hier: sowieso gut belegten) 80 MHz-Kanal.

Weitere, eher subjektive Ergebnisse insbes. auch auf die Reichweite bezogen erlange ich leider erst, wenn der Router dann als AP eine ältere Lösung ersetzt. Außerdem fällt mir gerade auf, dass ich überhaupt nicht im 2,4 GHz-Spektrum unterwegs war, was dann wiederum relevant(er) sein wird. So ist das halt erstmal...

Besten Dank dafür - bei Amazon.es (hier) hatte ich vor dem Einreichen des Deals tatsächlich auch geschaut, zu diesem Zeitpunkt war es dort (wenn ich keinen Fehler gemacht habe) noch deutlich teurer.

Italien (dort) hatte ich nicht mit auf dem Schirm.

Nehme ich oben mit auf, Danke!
Der Händler dahinter (nämlich Zyxel selbst) ist ja jeweils identisch... (bearbeitet)

Korrekt, scheint nicht möglich zu sein. Weder im Datenblatt noch im Handbuch steht dazu irgendetwas beschrieben.

Jo, geht problemlos: openwrt.org/doc…bap

Das willst du dann vermutlich noch mit 802.11r (Fast Transition) kombinieren, dann hast du das, was man heutzutage häufig Mesh nennt, nur eben mit Ethernet-Backhaul statt Wireless.

Wenn du ein komplettes Mesh haben willst (also auch mit Wireless-Backhaul), wären entweder WDS (praktisch bei z. B. zwei APs mit Ethernet-Backhaul und einer mit WDS-Backhaul) oder B.A.T.M.A.N. (besser bei mehreren APs mit Wireless-Backhaul) die Stichworte.

Wenn ich das richtig sehe, gibt es das. Nicht für "dreifuffzich", aber das dürfte klar sein.
Ob das sinnvoll ist, ist eine andere Frage. Siehe jedenfalls hier:

Highlights of device support
[...]
- Support for devices with 2.5G PHYs
- Acer Predator W6 (MT7986A), [...] ZyXEL EX5700 (MT7986)
- Support for Wifi 6E (6GHz)
- Acer Predator W6 (MT7986A), ZyXEL EX5700 (MT7986)

Zumindest der Acer scheint auch käuflich für rund 200€ erwerben zu sein, der ZyXEL ist offenbar erstmal nur ein Provider-Gerät (Telenor). (bearbeitet)

Die Problematik liest sich für mich so, als könne es dafür sehr viele verschiedene Ursachen geben - z.B. vom Internetanschluss über das (nicht weiter spezifizierte) AmpliFi-System bis hin zum Rechner selbst.
Daher würde ich in einer solchen Situation erstmal auf Fehlersuche gehen - insbesondere den Rechner direkt am Modem anschließen / mit dem Modem verbinden und das Ganze noch mit einem weiteren Rechner gegenchecken; möglicherweise (sofern sinnvoll) mal Kabel tauschen und/oder die gesamte WiFi-Strecke unter Last setzen und beobachten etc. pp. .

Wahllos Teile blind zu tauschen kann natürlich auch Erfolg bringen (und manchmal am Ende einer Diagnose nötig sein, bestenfalls erst per Leihgerät zum Probieren). Schöner ist es aber natürlich zu wissen, woran es genau mangelt und dann qualifiziert Konsequenzen zu ziehen.

Ich betrachte mich nicht als Profi, habe jedoch hier und da ein paar Zahlen gefunden. Auf der Basis würde ich mal schätzen, dass die Geräte bezogen auf's WiFi ähnlich laufen. Wobei der Aruba nochmal einen deutlich flotteren Prozessor und zumindest von Haus aus DFS zu haben scheint. Ohne handfesten Grund würde ich da wohl nicht wechseln.

Aber vielleicht kann jemand noch konkreter helfen.

Danke dir.

Wenn man die Infos sowieso für sich schon zusammenkratzt und in alten Deals hier nicht findet (oder nicht finden kann, sie zu jung sind), ist der Weg zwar immer noch mit etwas Fleißarbeit verbunden, aber nicht mehr ganz so weit und ein Nutzen hoffentlich (und vielleicht auch für Folgedeals) gegeben.

OMG eine webseite mit einem Text wäre so viel besser als Anleitung statt ein Video.

Ist sicherlich nicht für jede(n) etwas.

Auf meiner (bislang kleinen) Reise bin ich (siehe oben) hier und da schon vorbeigekommen; das Thema Mesh habe ich (insbes. mangels Relevanz für mich) noch nicht bearbeitet. Im verlinkten Tutorial ist in Kommentaren (-> oft lohnenswert zu lesen) auch die Schreibe davon, dass eine Mesh-Folge kommen soll - Zeitpunkt leider noch ungewiss. Zur Not müssen eben andere Quellen ran.

Abseits davon: Mir hilft es jedenfalls sehr, völlig unabhängig von geplanten Einsatzszenarien sich erstmal überhaupt einen Überblick über OpenWRT zu verschaffen und etwas geführter durch die Dialoge zu springen.

Und: Es kann wohl (lt. Dev-Faden) sein, dass es im Mesh-Kontext noch nicht ganz rund läuft, wobei ich verstanden habe, dass eine entsprechende Fehlerbehebung quasi auf dem Weg ist.

In der Tat gibt es auch einen (oder mehrere?) Mesh-Fa(e)den für den WSM20 hier, in dem auch ein paar weitere Quellen zum Thema im Benutzer-Leitfaden zu OpenWRT verlinkt sind.

Sorry, dass ich (noch?) nicht konkret weiterhelfen kann.
Aber vielleicht kann ja wer anders einspringen?

P.S.: Hier gibt's mittlerweile auch einen Link zur Basis-Firmware zurück. Ob das wirklich der ist, der aus der Kommunikation der Geräte abgegriffen wurde / den auch die Router zum Abruf nutzen, weiß ich natürlich nicht. (bearbeitet)

Die Belegung der WiFi-Kanäle hast du ja sicherlich schon gescanned und entsprechend reagiert.
Einen Tipp möchte ich noch einwerfen:
Wenn du demnächst ein paar Geräte mehr zur Verfügung hast , kannst du z.B. auch ein eigenes IoT-WiFi mit IEEE802.11b und ggf. sogar gedrosselter Geschwindigkeit versuchen, falls OpenWRT das hinbekommt (wovon ich mal schwer ausgehe - bald geht's los... ). (bearbeitet)

Wie oben bei "abercrombie" weiter oben wird es wohl auch hier so sein, dass der Durchsatz verglichen zur aktuellen Lösung voraussichtlich (deutlich) schlechter ist - zumindest dann, wenn man z.B. mit dem (an sich besseren) Multy U das Multy M1 annähert und dann hier in die Tabelle schaut - zumindest dann, wenn die Geräteanzahl gleich bleibt.