Lo stick GPON DFP-34X-2C2 compare in dmesg solo dopo decine di secondi e poi fa link a 1G
Sto sostituendo l'ONT dell'operatore con uno stick GPON SFP sulla macchina Linux che termina la nostra WAN, e lo stick non si comporta per niente come un transceiver. Lo inserisci e l'alloggiamento resta silenzioso per mezzo minuto o più, abbastanza a lungo che due volte ho pensato che il modulo fosse morto, e quando il kernel finalmente se ne accorge il link si assesta a velocità gigabit, il che vanifica lo scopo dell'esercizio.
Il banco:
- macchina router Linux, alloggiamento SFP pilotato dal layer SFP del kernel, kernel mainline
- stick GPON ODI DFP-34X-2C2
- uno stick Huawei MA5671a come secondo campione
- un normale modulo in fibra 1G che appare istantaneamente nello stesso alloggiamento, quindi l'alloggiamento in sé va bene
$ 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 offProvato finora:
- ho reinserito lo stick e l'ho lasciato stare per diversi minuti prima di toccare l'interfaccia, e l'attesa c'è ogni volta, non solo al primo inserimento
- ho fatto un bounce dell'interfaccia dopo il rilevamento, il che non cambia niente riguardo alla modalità negoziata
- l'MA5671a mostra la stessa comparsa lenta, quindi non è un campione difettoso isolato
È semplicemente così che si comportano gli stick GPON su un host Linux, o sto sbagliando qualcosa dal mio lato? Cosa sta davvero succedendo tra l'inserimento e il rilevamento qui?
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
Prima che inizino le congetture, due cose da chiarire. Primo, posta il dmesg non tagliato dall'inserimento in poi invece di un grep di due righe. Dici che l'alloggiamento sta dietro il layer SFP del kernel e non ho motivo di dubitarne, ma le righe che hai filtrato via sono quelle che mostrano quante volte il modulo è stato sondato, cosa ha rinunciato nel mezzo e quanto è durato ogni tentativo.
Secondo, cosa dichiara di poter fare l'interfaccia stessa una volta che lo stick è finalmente su, e 2500baseX compare da qualche parte nelle modalità annunciate? E che velocità ti sta dando l'ISP sul lato PON, dato che se è un piano gigabit allora il link che stai ottenendo è quello corretto e non c'è niente da sistemare.
Comportamento atteso, purtroppo, e non è il tuo host.
Uno stick GPON non è un transceiver con dentro un chip EEPROM. È un piccolo computer Linux sul proprio SoC, stipato in un guscio SFP, e l'EEPROM che il tuo host legge via I2C è emulata da quel sistema. Niente risponde sul bus finché il firmware dello stick stesso non si è avviato abbastanza da servire quelle pagine, ed è per questo che resti lì seduto per decine di secondi mentre un modulo normale risponde immediatamente. Quel silenzio prima della tua riga del modulo è il boot.
La seconda metà del tuo problema è che quello che le pagine emulate dichiarano è spesso semplicemente sbagliato. L'interfaccia lato host su questi stick è 2500BASE-X, e l'EEPROM dice qualcos'altro, quindi il layer SFP lo prende per buono e si assesta sulla modalità gigabit. Entrambe le metà sono gestite nel kernel con quirk per modulo piuttosto che con qualcosa che puoi configurare, e il DFP-34X-2C2 OEM ha ereditato uno di quei quirk proprio per questo motivo.
Se il tuo campione ci rientra dipende dalle stringhe vendor e part che riporta, e quelle differiscono tra i rebadge, quindi confronta cosa stampa la tua riga di dmesg con cosa fa match il quirk prima di dare per scontato di essere coperto.
Per sottolineare perché serva proprio l'approccio a quirk: SFF-8472 presuppone un dispositivo di memoria passivo che risponde entro i tempi I2C ordinari. Niente in esso contempla un dispositivo che ha bisogno di mezzo minuto di boot prima di poter parlare, quindi un host che segue lo standard ha tutto il diritto di rinunciare sul modulo o di fidarsi dei bit di modalità che alla fine legge.
Il punto sui rebadge sopra è la trappola pratica. Il match avviene sulle stringhe vendor e part, quindi lo stesso stick fisico venduto sotto un altro nome manca completamente il quirk e ti ritrovi con un link gigabit senza motivo apparente. E non costruire niente che dipenda dal modulo presente poco dopo il boot, perché qui quella corsa è invincibile.
Sperare che i vendor degli stick sistemino il contenuto della loro EEPROM è ottimistico anche quello. Quando questi problemi sono stati sollevati, anche grandi ISP ne hanno ricevuto ben poco indietro.
Stessa classe di problema salta fuori sui router consumer, quindi almeno sei in compagnia. I proprietari di Archer BE800, BE900 e GE800 con uno stick nella porta combo SFP+ 10G ottengono 1 Gbit/s invece dei 2,5 che pagano, e la lista di TP-Link stessa degli stick segnalati funzionare in quelle porte è l'ODI DFP-34X-2C2, l'Huawei MA5671A e il Nokia G-010SA, che è la stessa lista corta di parti a cui tutti finiscono per arrivare.
Il consiglio di prima linea lì era firmware più reinserimento, e la parte del reinserimento non è una sciocchezza, un modulo che non è scattato fino in fondo davvero retrocede. Le build beta alla fine hanno esposto la configurazione della porta, una per modello:
Con una di quelle sul box la modalità della porta SFP diventa impostabile via telnet, interfaccia abbassata prima,
ip link set eth1 downe così via.Resta comunque un workaround e non una correzione, bada bene. Un anno dopo arrivavano gli stessi reclami, e non solo sugli stick: una persona aveva un AOC JT-AOC-SFP-15 di JT-COM in quella porta, un'altra un DAC SFP+ 10G passivo di Ampcom, ed entrambi stavano a 1 Gbit/s.
Vale la pena conoscere l'altra modalità di fallimento prima che qualcuno suggerisca di spostare lo stick su una NIC. Su OpenWrt 19.07 su x86 con un Intel X520 e kmod-ixgbe, un MA5671a viene semplicemente rifiutato come SFP non supportato. Impostare allow_unsupported_sfp attraverso i soliti file di configurazione dei moduli lì non fa assolutamente niente, il parametro deve essere passato quando il modulo viene caricato:
E anche con quello il driver lo rifiuta comunque, perché l'EEPROM dello stick non descrive innanzitutto un transceiver normale e il flag non può nasconderlo. Se finisci davvero su una NIC, prova la porta prima con un normale modulo 1000BASE-T, LX o SX, altrimenti stai facendo debug della scheda e dello stick allo stesso tempo.
Attenzione però a non confondere le due cose. allow_unsupported_sfp vive dentro ixgbe e decide se quel driver è disposto a pilotare affatto una data ottica, che è una decisione diversa da quella presa qui. La lunga attesa e la modalità sbagliata vengono dal layer SFP generico che legge le pagine emulate e passa il risultato su a phylink, ed è lì che stanno i quirk per modulo.
Su una scheda con un vero alloggiamento SFP il flag di ixgbe non esiste e non è la correzione, e su un X520 nemmeno la lista dei quirk ti salverà. Stesso sintomo in superficie, strato diverso sotto, e confonderli è come la gente finisce per ricompilare driver per niente.
Un altro confine che vale la pena tracciare visto che ci sei: far vedere lo stick all'host e far accettare l'OLT sono problemi indipendenti, e il secondo può essere molto peggiore.
C'è un caso ben documentato di un Xicom DFP-34X-2C2 caricato con l'identità copiata da uno ZTE ZXHN F601 con setmac e query OMCI, seriale GPON, password PLOAM, LOID, seriale hardware e stringa firmware, tutto quanto. Lo stick arriva allo stato O5 e poi resta lì fermo, nessun ONU ID assegnato e nessun traffico, perché raggiungere O5 significa solo che il ranging ha funzionato mentre l'upload del MIB deve ancora corrispondere al profilo ONT che l'OLT si aspetta. Nessuno in quel thread ha prodotto una correzione.
Quindi quando ottieni 2500BASE-X in locale, non dare per scontato che la parte difficile sia alle spalle. Dove l'operatore lega un profilo di servizio a un modello ONT specifico, potrebbe non esserci nessun insieme di campi copiati che fa accettare uno stick di terze parti.