Turris Omnia weigert een unlocked MA5671A GPON-stick: eth2 komt nooit op onder Turris OS 5.0.3
Ik probeer het ISP-terminal in mijn thuisrack te vervangen door een GPON-stick rechtstreeks in de router, zodat de fiber in één kastje landt in plaats van twee. De stick wordt herkend, en daar houdt het goede nieuws op.
- Turris Omnia op Turris OS 5.0.3, stock kernel
- Huawei MA5671A GPON-stick met unlocked firmware, ingesteld op SGMII 1G
- SC/APC-pigtail van het wandcontact naar de stick
- eth2 is de SFP-poort
De module wordt gedetecteerd, maar de interface activeert nooit:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 blijft daarna down, geen carrier, niets in de counters.
Wat ik tot nu toe geprobeerd heb:
- de stick terugflashen naar stock firmware, wat me in plaats daarvan een EEPROM read error oplevert
- de snelheid forceren met ethtool -s eth2 1000 autoneg off duplex full, waarna de interface op 10 Mbit half duplex blijft staan
- dezelfde stick in een MikroTik-router zetten, waar hij wel opkomt zodra de poortsnelheid met de hand wordt ingesteld
Dus de module zelf leeft en de fiber-kant is in orde. Wat is het in de stick waar de kernel bezwaar tegen maakt, en welke GPON-sticks komen op een Omnia daadwerkelijk op in plaats van geweigerd te worden?
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
Dit is een probleem aan de host-kant, geen dode module. De EEPROM in deze omgebouwde GPON-sticks declareert een encoding die de mainline sfp-driver niet kan mappen, phylink weigert daarom de poort omhoog te brengen, en de regel die je plakte is de driver die precies dat zegt. Je eigen bewijs wijst dezelfde kant op: dezelfde stick linkt op een MikroTik zodra de poortsnelheid met de hand wordt ingesteld, dus de optics en de PON-kant zijn in orde.
Het enige dat bij mij iets veranderde was een kernel nieuw genoeg om de per-module quirks mee te dragen, en dat betekende op de Omnia de HBD testing branch met kernel 5.4. Let wel op: dit is een gedeeltelijke overwinning en hangt sterk af van welke stick je hebt. Op die kernel:
Dus als je de Omnia nu wilt laten werken in plaats van ooit, is de DFP-34G-2C2 degene die ik in de cage zou zetten. Test hem eerst op je eigen box voor je je vastlegt, de resultaten hier verschillen duidelijk tussen sticks en zelfs tussen firmwarerevisies van dezelfde stick.
Twee dingen de moeite waard om vast te pinnen voor iemand begint te gokken. Ten eerste, van welke branch komt die 5.0.3 en welke kernel meldt uname? De per-module SFP quirks die deze omgebouwde GPON-sticks nodig hebben, kwamen later binnen, dus een uitgebrachte stable kernel en een testing-kernel gedragen zich heel anders met exact dezelfde module.
Ten tweede, is het ONU-serienummer aan de providerkant geregistreerd? Een stick die nooit op de OLT geautoriseerd raakt, blijft daar dood ogend zitten, en heel wat providers weigeren sowieso een ONU van een derde te registreren.
En als je hem insteekt, schakelt de poort ooit naar inband/1000base-x, of stopt het log precies bij die encoding-melding?
Stable branch, stock kernel voor 5.0.3, niets custom erbovenop. De providerkant is hier niet het probleem, het is dezelfde fiber en de stick draagt het geregistreerde serienummer.
Het log stopt bij de encoding-regel, de poort schakelt nooit naar inband/1000base-x. Wat ik krijg hangt af van de firmware. Met de unlocked versie:
plus een transmit fault die de module rapporteert. Met stock firmware komt hij niet eens zo ver:
En zoals gezegd, de snelheid forceren doet helemaal niets: na ethtool -s eth2 1000 autoneg off duplex full blijft de interface nog steeds op 10 Mbit half duplex staan.
Nog een storingsmodus om op dezelfde router uit te sluiten, want hij lijkt erop maar heeft niets met de encoding te maken. Een HALNy HL-GSFP op Turris OS HBS 6.2.4 werd gedetecteerd, de poort schakelde zelfs naar inband/1000base-x, en toen viel de link weg en bleef eth2 down.
Oorzaak: die stick is op zichzelf een kleine computer. Hij besteedt zo'n minuut aan het opstarten van zijn eigen firmware, en pas daarna antwoordt hij de cage met iets zinnigs. Bij een koude boot kijkt de router al lang voor dat moment in de cage, dus mislukt de detectie en valt de box stilletjes terug op de koperen WAN-magnetics. De bootdelay verlengen loste het op:
Zestig seconden in plaats van de standaard drie, en iemand anders met dezelfde stick bevestigde het. Nog twee dingen die hielpen: de koperen WAN-kabel loskoppelen en nog een keer rebooten, en inloggen op de module zelf om te zien in welke staat hij is, over serieel op 38400 8N1 of over SSH op 192.168.77.154 poort 22666.