Zyxel M1 – Probleme an 100-MBit/s-Switch / möglicher EEE-Zusammenhang

Firmware
1

Hallo zusammen,

ich habe aktuell an einem Standort in einer Bäckerei ein reproduzierbares Problem mit einem Zyxel M1 und wollte das hier einmal sauber dokumentieren.

Vor Ort ist vorne im Kassenbereich ein älterer TP-Link-Switch mit 100 MBit/s verbaut. An genau diesem Anschluss geht der Zyxel M1 regelmäßig beziehungsweise dauerhaft offline.

Zum Gegencheck habe ich dasselbe Gerät mit nach Hause genommen und dort an meinem Telekom Speedport Smart 7 angeschlossen. Dort ist der Knoten unmittelbar wieder online gekommen und läuft stabil.

An zwei weiteren Standorten habe ich ebenfalls Zyxel-M1-Geräte neu eingesetzt; dort liefen sie von Anfang an ohne Auffälligkeiten.

Daher liegt für mich aktuell der Verdacht nahe, dass das Problem mit der 100-MBit/s-Ethernet-Verbindung beziehungsweise EEE (Energy Efficient Ethernet) zusammenhängen könnte.

Passend dazu gibt es bei OpenWrt bereits folgenden Pull Request beziehungsweise Fix:

https://shorturl.at/Y7QZO

Soweit ich das aktuell verstehe, geht es dort darum, EEE bei betroffenen MediaTek-Switches beziehungsweise SoCs gezielter zu deaktivieren, weil die bisherige Behandlung offenbar nicht in allen Konstellationen ausreichend ist.

Mir ist natürlich bewusst, dass damit noch nicht bewiesen ist, dass exakt dieser OpenWrt-Bug auch die Ursache bei meinem Standort ist. Das Fehlerbild passt allerdings zumindest auffällig gut dazu:

  • Zyxel M1 an 100-MBit/s-TP-Link-Switch → Probleme / offline

  • derselbe Zyxel M1 zuhause an aktueller Gigabit-Infrastruktur → sofort online und stabil

  • weitere Zyxel M1 an zwei anderen Standorten → problemlos

Ich wusste bei der Installation selbst nicht, dass diese Geräte in Verbindung mit älteren 100-MBit/s-Netzwerken möglicherweise solche Probleme verursachen können. Deshalb habe ich den Knoten dort zunächst genauso eingesetzt wie an den anderen Standorten.

Mich würde daher interessieren:

Hat jemand von euch mit dem Zyxel M1 und der aktuellen 4830.org-Firmware beziehungsweise Gluon v2025.1 schon ähnliche Erfahrungen mit 100-MBit/s-Switches oder EEE gemacht?

Gibt es dafür bereits bekannte Workarounds oder einen Patch, den man testweise in einer Beta-Firmware übernehmen könnte?

Als kurzfristige Lösung werde ich voraussichtlich den 100-MBit/s-Switch durch einen einfachen Gigabit-Switch ersetzen beziehungsweise testweise einen Gigabit-Switch zwischen den bestehenden Switch und den Zyxel M1 hängen.

Wenn ihr noch bestimmte Informationen braucht – genaue Firmware-Version, Modell des TP-Link-Switches, Link-Status, Logs oder weitere Tests – kann ich das gerne nachreichen.

Viele Grüße
Adrian
Freifunk Brilon

2

Der bezieht sich aber auf OpenWrt 25.10, oder? Wir haben in 2.1/Gluon v2025.1 aber eine OpenWrt 24-Basis … Muß ich mir mal in Ruhe ansehen.

3

Nachdem was ich rausgefunden habe, wohl ja ich nutze hier aktuell von euch tng beim Zyxel M1

4

Moin @wusel dein Update hat direkt geholfen :folded_hands:

5

Gluon v2025.1 hat den Fix 926314a drin. Der reicht aber in der speziellen Konstellation in Kernel 6.x nicht mehr. Nach kurzer Diskussion mit Felix vom Freifunk Aachen hat mein neuer Kollege ChatGPT, mit lenkender Hilfestellung durch mich (»Das hätte ich beim ersten Patch sauberer behandeln müssen«, wir kennen das ja ;-)) auf Basis des relevanten Patches einen solchen für Gluon v2025.1 erstellt, mit dem dann heute Nacht 2.1.0~52 gebaut wurde. Dieser löst augenscheinlich Andrias Problem, in neueren OpenWrt-Versionen (⇒ Gluon v2026.1) ist der von Haus aus enthalten …

(Nein, KI war da nicht notwendig, ich hätte nur Pfade und Zeilennummern anpassen müssen, und dann aus dem OpenWrt-Patch einen Gluon-Patch-für-OpenWrt machen müssen, um daraus schließlich einen Patch-für-Gluon-damit-es-den-Patch-für-OpenWrt-hinzufügt zu machen. Letztere kommt in site/patches und wird dann beim make applied. Also: Makefile in site-Repo checkt Gluon aus, fügt dort den Patch für OpenWrt hinzu, Gluons Makefile checkt dann OpenWrt aus und fügt dort den Patch für das ramips-Target hinzu, OpenWrts Makefile wiederum checkt den Linux-Kernel aus und patcht dort die relevanten Dateien. Diese ganzen Automatismen machen das etws trickreich, und da hilft die KI einfach, Zeit zu sparen, in den 6 Minuten, die die KI für zwei Durchläufe gebraucht hat, hätte ich das nicht auf dem klassischen Weg – Datei im Tree ändern, git add, git commit, git format-patch -1 HEAD, Patch in OpenWrt-Tree an richtige Stelle schieben, git add, git commit, git format-patch -1 HEAD, Patch in Gluon-Tree an richtige Stelle schieben, git add, git commit, git format-patch -1 HEAD, Patch von Buildhost in lokales site-Repo kopieren, git add, git commit, git push – umgesetzt.)