Turris Omnia verweigert einen entsperrten MA5671A GPON-Stick: eth2 kommt auf Turris OS 5.0.3 nie hoch
Ich versuche, das Provider-Terminal in meinem Rack zu Hause durch einen GPON-Stick direkt im Router zu ersetzen, damit die Faser in einer Box landet statt in zweien. Der Stick wird erkannt, und da hören die guten Nachrichten auch schon auf.
- Turris Omnia auf Turris OS 5.0.3, Stock-Kernel
- Huawei MA5671A GPON-Stick mit entsperrter Firmware, eingestellt auf SGMII 1G
- SC/APC-Pigtail von der Wanddose zum Stick
- eth2 ist der SFP-Port
Das Modul wird erkannt, aber das Interface aktiviert sich nie:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 bleibt danach down, kein Carrier, nichts in den Zählern.
Was ich bisher versucht habe:
- den Stick zurück auf Stock-Firmware geflasht, was mir stattdessen einen EEPROM-Lesefehler einbringt
- die Rate mit ethtool -s eth2 1000 autoneg off duplex full erzwungen, danach sitzt das Interface bei 10 Mbit Halbduplex
- denselben Stick in einen MikroTik-Router gesteckt, wo er hochkommt, sobald die Portgeschwindigkeit von Hand gesetzt wird
Das Modul selbst lebt also, und die Faserseite ist in Ordnung. Was ist es am Stick, wogegen der Kernel sich sperrt, und welche GPON-Sticks kommen auf einer Omnia tatsächlich hoch, statt abgewiesen zu werden?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Das ist ein Problem auf der Host-Seite, kein totes Modul. Das EEPROM in diesen zweckentfremdeten GPON-Sticks deklariert eine Codierung, die der Mainline-sfp-Treiber nicht abbildet, phylink weigert sich deshalb, den Port hochzufahren, und die Zeile, die du gepostet hast, ist der Treiber, der genau das sagt. Deine eigene Beobachtung zeigt in dieselbe Richtung: Derselbe Stick linkt an einem MikroTik, sobald die Portgeschwindigkeit von Hand gesetzt wird, also sind die Optik und die PON-Seite in Ordnung.
Das Einzige, was bei mir etwas bewegt hat, war ein Kernel, der neu genug ist, um die Quirks pro Modul mitzubringen, auf der Omnia hieß das der HBD-Testzweig mit Kernel 5.4. Vorsicht: Das ist nur ein Teilerfolg und hängt stark davon ab, welchen Stick man hat. Auf diesem Kernel:
Wer die Omnia also jetzt zum Laufen bringen will statt irgendwann, für den wäre das DFP-34G-2C2 das, was ich in den Käfig stecken würde. Auf dem eigenen Gerät testen, bevor man sich festlegt, die Ergebnisse hier schwanken klar zwischen Sticks und sogar zwischen Firmware-Revisionen desselben Sticks.
Zwei Dinge, die man festnageln sollte, bevor jemand zu raten anfängt. Erstens: Aus welchem Zweig stammt dieses 5.0.3, und welchen Kernel meldet uname? Die Quirks pro Modul, die diese zweckentfremdeten GPON-Sticks brauchen, sind später gelandet, ein ausgeliefertes Stable-Kernel und ein Testing-Kernel verhalten sich also bei genau demselben Modul sehr unterschiedlich.
Zweitens: Ist die ONU-Seriennummer auf der Provider-Seite registriert? Ein Stick, der auf dem OLT nie autorisiert wird, sitzt da und sieht tot aus, und etliche Provider weigern sich rundweg, eine Dritt-ONU zu registrieren.
Und wenn du ihn einsteckst, wechselt der Port dabei überhaupt zu inband/1000base-x, oder bricht das Log genau bei dieser Encoding-Meldung ab?
Stable-Zweig, Stock-Kernel für 5.0.3, nichts Eigenes obendrauf. Die Provider-Seite ist hier nicht das Problem, es ist dieselbe Faser, und der Stick trägt die registrierte Seriennummer.
Das Log bricht bei der Encoding-Zeile ab, der Port kippt nie in inband/1000base-x. Was ich bekomme, hängt von der Firmware ab. Mit der entsperrten:
dazu ein vom Modul gemeldeter Transmit Fault. Mit Stock-Firmware kommt es nicht mal so weit:
Und wie gesagt, die Rate zu erzwingen bringt gar nichts: Nach ethtool -s eth2 1000 autoneg off duplex full sitzt das Interface immer noch bei 10 Mbit Halbduplex.
Noch ein Fehlerbild, das man am selben Router ausschließen sollte, weil es ähnlich aussieht und mit der Codierung nichts zu tun hat. Ein HALNy HL-GSFP auf Turris OS HBS 6.2.4 wurde erkannt, der Port wechselte sogar zu inband/1000base-x, dann brach der Link ab und eth2 blieb down.
Ursache: Dieser Stick ist für sich genommen ein kleiner Computer. Er braucht etwa eine Minute, um seine eigene Firmware hochzufahren, und erst danach antwortet er dem Käfig mit irgendetwas Sinnvollem. Bei einem Kaltstart schaut der Router schon lange vor diesem Zeitpunkt in den Käfig, die Erkennung schlägt also fehl, und die Box fällt still auf die Kupfer-WAN-Magnetics zurück. Das Verlängern des Boot-Delays hat es behoben:
Sechzig Sekunden statt der Default-drei, und jemand anderes mit demselben Stick hat es bestätigt. Zwei weitere Dinge, die geholfen haben: das Kupfer-WAN-Kabel abziehen und noch einmal neu starten, und sich direkt beim Modul einloggen, um zu sehen, in welchem Zustand es ist, über seriell mit 38400 8N1 oder über SSH auf 192.168.77.154 Port 22666.