Turris Omnia rifiuta uno stick GPON MA5671A sbloccato: eth2 non sale mai su Turris OS 5.0.3
Sto cercando di sostituire il terminale dell'ISP nel mio rack di casa con uno stick GPON direttamente nel router, così la fibra atterra in una scatola sola invece che in due. Lo stick viene riconosciuto, ed è lì che finiscono le buone notizie.
- Turris Omnia su Turris OS 5.0.3, kernel stock
- stick GPON Huawei MA5671A con firmware sbloccato, impostato su SGMII 1G
- pigtail SC/APC dalla presa a muro allo stick
- eth2 è la porta SFP
Il modulo viene rilevato ma l'interfaccia non si attiva mai:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 resta down dopo, nessun carrier, niente nei contatori.
Cosa ho provato finora:
- flashare lo stick di nuovo al firmware stock, il che mi dà invece un errore di lettura EEPROM
- forzare il rate con ethtool -s eth2 1000 autoneg off duplex full, dopo di che l'interfaccia si ferma a 10 Mbit half duplex
- spostare lo stesso stick in un router MikroTik, dove sale una volta impostata a mano la velocità della porta
Quindi il modulo in sé è vivo e il lato fibra va bene. Cosa c'è nello stick a cui il kernel obietta, e quali stick GPON salgono davvero su un Omnia invece di essere rifiutati?
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
Questo è un problema lato host, non un modulo morto. L'EEPROM di questi stick GPON riadattati dichiara una codifica che il driver sfp mainline non riesce a mappare, quindi phylink si rifiuta di portare su la porta, e la riga che hai incollato è il driver che dice esattamente questo. Anche le tue prove puntano nella stessa direzione: lo stesso identico stick fa link su un MikroTik una volta impostata a mano la velocità della porta, quindi l'ottica e il lato PON vanno bene.
L'unica cosa che ha smosso qualcosa per me è stato un kernel abbastanza recente da portare le quirk per singolo modulo, che sull'Omnia significava il branch di test HBD con kernel 5.4. Attenzione, è una vittoria parziale e dipende molto da quale stick hai. Su quel kernel:
Quindi se vuoi l'Omnia funzionante adesso invece che eventualmente, il DFP-34G-2C2 è quello che metterei nella cage. Testalo sulla tua macchina prima di deciderti, qui i risultati variano chiaramente tra stick e persino tra revisioni di firmware dello stesso stick.
Due cose da chiarire prima che qualcuno inizi a tirare a indovinare. Primo, da quale branch viene quella 5.0.3 e cosa riporta uname come kernel? Le quirk SFP per singolo modulo di cui hanno bisogno questi stick GPON riadattati sono arrivate più tardi, quindi un kernel stable rilasciato e uno di test si comportano in modo molto diverso con esattamente lo stesso modulo.
Secondo, il seriale dell'ONU è registrato lato provider? Uno stick mai autorizzato sull'OLT se ne starà lì sembrando morto, e parecchi provider si rifiutano proprio di registrare un ONU di terze parti.
E quando lo colleghi, la porta arriva mai a passare a inband/1000base-x, o il log si ferma proprio a quel messaggio di encoding?
Branch stable, kernel stock per la 5.0.3, niente di custom sopra. Il lato provider non è il problema qui, è la stessa fibra e lo stick porta il seriale registrato.
Il log si ferma alla riga di encoding, la porta non passa mai a inband/1000base-x. Quello che ottengo dipende dal firmware. Con quello sbloccato:
più un transmit fault segnalato dal modulo. Con il firmware stock non arriva nemmeno fin lì:
E come detto, forzare il rate non cambia assolutamente nulla: dopo ethtool -s eth2 1000 autoneg off duplex full l'interfaccia resta comunque a 10 Mbit half duplex.
Un'altra modalità di guasto da escludere sullo stesso router, perché sembra simile ma non ha niente a che fare con l'encoding. Un HALNy HL-GSFP su Turris OS HBS 6.2.4 veniva rilevato, la porta passava persino a inband/1000base-x, poi il link cadeva ed eth2 restava down.
Causa: quello stick è un piccolo computer a sé stante. Ci mette circa un minuto a portare su il proprio firmware, e solo dopo risponde alla cage con qualcosa di sensato. A un cold boot il router guarda dentro la cage molto prima di quel momento, quindi il rilevamento fallisce e la scatola torna silenziosamente sulla parte magnetica del WAN in rame. Allungare il boot delay ha risolto:
Sessanta secondi invece dei tre di default, e qualcun altro con lo stesso stick l'ha confermato. Altre due cose che hanno aiutato: staccare il cavo WAN in rame e riavviare un'altra volta, e collegarsi al modulo stesso per vedere in che stato è, via seriale a 38400 8N1 oppure via SSH su 192.168.77.154 porta 22666.