GPON-stick DFP-34X-2C2 verschijnt pas na tientallen seconden in dmesg en linkt dan op 1G
Ik ben de operator-ONT aan het vervangen door een SFP GPON-stick op de Linux-box die onze WAN termineert, en de stick gedraagt zich helemaal niet als een transceiver. Steek hem erin en de cage blijft een halve minuut of langer stil, lang genoeg dat ik twee keer dacht dat de module dood was, en als de kernel hem eindelijk opmerkt settelt de link op gigabit-snelheid, wat het hele punt van de oefening tenietdoet.
De bank:
- Linux router-box, SFP-cage aangestuurd door de kernel SFP-laag, mainline kernel
- ODI DFP-34X-2C2 GPON-stick
- een Huawei MA5671a stick als tweede sample
- een gewone 1G fibermodule die meteen verschijnt in dezelfde cage, dus de cage zelf is prima
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offTot nu toe geprobeerd:
- de stick opnieuw gezet en enkele minuten met rust gelaten voordat ik de interface aanraakte, en de wachttijd is er elke keer, niet alleen bij de eerste keer insteken
- de interface bounced na detectie, wat niets verandert aan de onderhandelde mode
- de MA5671a laat hetzelfde trage verschijnen zien, dus het is niet één slecht sample
Is dit gewoon hoe GPON-sticks zich gedragen op een Linux-host, of doet mijn kant iets verkeerd? Wat gebeurt er hier eigenlijk tussen insteken en detectie?
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 7
Voordat het gokken begint, twee dingen de moeite waard om vast te leggen. Ten eerste: post de ongetrimde dmesg vanaf het insteken in plaats van een grep van twee regels. Je zegt dat de cage achter de kernel SFP-laag zit en ik heb geen reden om dat te betwijfelen, maar de regels die je eruit gefilterd hebt zijn precies de regels die laten zien hoe vaak de module geprobed is, wat er tussendoor opgaf en hoe lang elke poging duurde.
Ten tweede: wat beweert de interface zelf te kunnen zodra de stick eindelijk up is, en duikt 2500baseX ergens op in de geadverteerde modes? En welke snelheid geeft de ISP je aan de PON-kant, want als dat een gigabit-abonnement is, dan is de link die je krijgt de juiste en valt er niets te fixen.
Verwacht gedrag, helaas, en het ligt niet aan jouw host.
Een GPON-stick is geen transceiver met een EEPROM-chip erin. Het is een kleine Linux-computer op zijn eigen SoC, gepropt in een SFP-behuizing, en de EEPROM die jouw host over I2C leest wordt door dat systeem geëmuleerd. Er antwoordt niets op de bus totdat de eigen firmware van de stick ver genoeg is opgestart om die pagina's te serveren, en daarom zit je daar tientallen seconden terwijl een normale module meteen antwoordt. Die stilte voor jouw module-regel is het opstarten.
De tweede helft van jouw probleem is dat wat de geëmuleerde pagina's adverteren vaak gewoon fout is. De host-side interface op deze sticks is 2500BASE-X, en de EEPROM zegt iets anders, dus de SFP-laag neemt dat voor waar aan en settelt op de gigabit-mode. Beide helften worden in de kernel afgehandeld met per-module quirks in plaats van iets dat je kunt configureren, en de OEM DFP-34X-2C2 heeft precies om deze reden een van die quirks opgepikt.
Of jouw sample daarop terechtkomt hangt af van de vendor- en partstrings die hij rapporteert, en die verschillen tussen rebadges, dus vergelijk wat jouw dmesg-regel print met wat de quirk matcht voordat je aanneemt dat je gedekt bent.
Om te onderstrepen waarom de quirk-aanpak überhaupt nodig is: SFF-8472 gaat uit van een passief memory device dat binnen gewone I2C-timings antwoordt. Niets erin houdt rekening met een device dat een halve minuut opstarttijd nodig heeft voordat het kan praten, dus een host die de standaard volgt heeft alle recht om de module op te geven of om de mode-bits te vertrouwen die hij uiteindelijk leest.
Het rebadge-punt hierboven is de praktische valkuil. Er wordt gematcht op de vendor- en partstrings, dus dezelfde fysieke stick onder een andere naam verkocht mist de quirk volledig en je bent terug bij een gigabit-link zonder duidelijke reden. En bouw niets dat ervan afhankelijk is dat de module kort na het opstarten aanwezig is, want die race is hier niet te winnen.
Hopen dat de stickvendors hun EEPROM-inhoud fixen is ook optimistisch. Toen deze problemen aangekaart werden, kregen zelfs grote ISP's er weinig op terug.
Hetzelfde soort probleem duikt op bij consumentenrouters, dus je bent in elk geval in gezelschap. Eigenaren van de Archer BE800, BE900 en GE800 met een stick in de 10G SFP+ combopoort krijgen 1 Gbit/s in plaats van de 2,5 waarvoor ze betalen, en TP-Link's eigen lijst van sticks die gemeld zijn te werken in die poorten is de ODI DFP-34X-2C2, de Huawei MA5671A en de Nokia G-010SA, dezelfde korte lijst onderdelen waar iedereen op uitkomt.
Eerstelijns advies daar was firmware plus opnieuw insteken, en het opnieuw-insteken-deel is geen onzin, een module die niet helemaal is vastgeklikt valt echt terug. Beta-builds legden uiteindelijk port-configuratie bloot, één per model:
Met een van die op de box wordt de SFP-portmode instelbaar via telnet, interface eerst dropped,
ip link set eth1 downenzovoort.Nog steeds een workaround en geen fix, let wel. Een jaar later kwamen dezelfde klachten binnen, en niet alleen over sticks: iemand had een JT-AOC-SFP-15 AOC van JT-COM in die poort, een ander een passieve 10G SFP+ DAC van Ampcom, en beide zaten vast op 1 Gbit/s.
De moeite waard om het andere faalmodel te kennen voordat iemand voorstelt om de stick naar een NIC te verplaatsen. Op OpenWrt 19.07 op x86 met een Intel X520 en kmod-ixgbe wordt een MA5671a simpelweg geweigerd als unsupported SFP. allow_unsupported_sfp instellen via de gebruikelijke module-configbestanden doet daar helemaal niets, de parameter moet meegegeven worden op het moment dat de module geladen wordt:
En zelfs dan weigert de driver hem nog steeds, omdat de EEPROM van de stick om te beginnen geen normale transceiver beschrijft en de flag dat niet kan verbloemen. Als je toch op een NIC uitkomt, bewijs de poort eerst met een gewone 1000BASE-T, LX of SX module, anders zit je de kaart en de stick tegelijk te debuggen.
Wel oppassen om die twee niet door elkaar te halen. allow_unsupported_sfp zit binnen ixgbe en bepaalt of die driver bereid is om een gegeven optic überhaupt aan te sturen, een andere beslissing dan degene die hier gemaakt wordt. De lange wachttijd en de verkeerde mode komen van de generieke SFP-laag die de geëmuleerde pagina's leest en het resultaat doorgeeft aan phylink, en daar zitten de per-module quirks.
Op een board met een echte SFP-cage bestaat de ixgbe-flag niet en is hij niet de fix, en op een X520 redt de quirklijst je ook niet. Zelfde symptoom aan de oppervlakte, andere laag eronder, en ze door elkaar halen is hoe mensen drivers voor niets gaan herbouwen.
Nog een grens de moeite waard om te trekken terwijl je toch bezig bent: de host de stick laten zien en de OLT hem laten accepteren zijn onafhankelijke problemen, en het tweede kan veel erger zijn.
Er is een goed gedocumenteerd geval van een Xicom DFP-34X-2C2 geladen met de identity gekopieerd van een ZTE ZXHN F601 met setmac en OMCI queries, GPON serial, PLOAM password, LOID, hardware serial en firmware string, alles. De stick range naar O5-state en blijft dan gewoon hangen, geen ONU-ID toegewezen en geen verkeer, omdat O5 bereiken alleen betekent dat ranging werkte terwijl de MIB-upload nog steeds moet matchen met het ONT-profiel dat de OLT verwacht. Niemand in die thread kwam met een fix.
Dus als je lokaal wel 2500BASE-X krijgt, ga er niet van uit dat het moeilijke deel achter je ligt. Waar de operator een serviceprofiel aan één specifiek ONT-model koppelt, is er misschien geen set gekopieerde velden die een third-party stick geaccepteerd krijgt.