Turris Omnia rechaza un stick GPON MA5671A desbloqueado: eth2 nunca sube en Turris OS 5.0.3
Intentando sustituir el terminal del ISP en mi rack doméstico por un stick GPON directo en el router, para que la fibra llegue a una sola caja en vez de dos. El stick se detecta, y ahí terminan las buenas noticias.
- Turris Omnia con Turris OS 5.0.3, kernel de fábrica
- Stick GPON Huawei MA5671A con firmware desbloqueado, configurado en SGMII 1G
- Latiguillo SC/APC desde la roseta de pared hasta el stick
- eth2 es el puerto SFP
El módulo se detecta pero la interfaz nunca se activa:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 queda caído después de eso, sin portadora, nada en los contadores.
Lo que he probado hasta ahora:
- volver a flashear el stick con firmware de fábrica, lo que en cambio da un error de lectura de EEPROM
- forzar la velocidad con ethtool -s eth2 1000 autoneg off duplex full, tras lo cual la interfaz se queda a 10 Mbit half duplex
- pasar el mismo stick a un router MikroTik, donde sí sube una vez que se fija la velocidad del puerto a mano
Así que el módulo en sí está vivo y el lado de fibra está bien. ¿Qué hay en el stick que el kernel rechaza, y qué sticks GPON realmente suben en una Omnia en vez de ser rechazados?
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
Esto es un problema del lado del host, no un módulo muerto. La EEPROM de estos sticks GPON reutilizados declara una codificación que el driver sfp de mainline no mapea, por lo que phylink se niega a levantar el puerto, y la línea que has pegado es justo el driver diciendo eso. Tu propia evidencia apunta en la misma dirección: el mismo stick enlaza en un MikroTik en cuanto se fija la velocidad del puerto a mano, así que la óptica y el lado PON están bien.
Lo único que marcó la diferencia en mi caso fue un kernel lo bastante nuevo como para llevar las peculiaridades por módulo, que en la Omnia significó la rama de pruebas HBD con kernel 5.4. Aviso de que es una victoria parcial y depende mucho de qué stick tengas. En ese kernel:
Así que si quieres tener la Omnia funcionando ahora en vez de eventualmente, el DFP-34G-2C2 es el que yo pondría en la jaula. Pruébalo en tu propia máquina antes de comprometerte, aquí los resultados varían claramente entre sticks e incluso entre revisiones de firmware del mismo.
Dos cosas que conviene aclarar antes de que alguien empiece a adivinar. Primero, ¿de qué rama viene ese 5.0.3 y qué kernel reporta uname? Las peculiaridades por módulo SFP que necesitan estos sticks GPON reutilizados llegaron más tarde, así que un kernel estable publicado y uno de pruebas se comportan de forma muy distinta con exactamente el mismo módulo.
Segundo, ¿el número de serie de la ONU está registrado en el lado del proveedor? Un stick que nunca se autoriza en la OLT se quedará ahí pareciendo muerto, y muchos proveedores directamente se niegan a registrar una ONU de terceros.
Y cuando lo conectas, ¿el puerto llega a cambiar a inband/1000base-x, o el log se detiene justo en ese mensaje de codificación?
Rama estable, kernel de fábrica para 5.0.3, nada personalizado encima. El lado del proveedor no es el problema aquí, es la misma fibra y el stick lleva el número de serie registrado.
El log se detiene en la línea de codificación, el puerto nunca pasa a inband/1000base-x. Lo que obtengo depende del firmware. Con el desbloqueado:
más un fallo de transmisión reportado por el módulo. Con el firmware de fábrica ni siquiera llega tan lejos:
Y como dije, forzar la velocidad no hace nada: después de ethtool -s eth2 1000 autoneg off duplex full la interfaz sigue a 10 Mbit half duplex.
Otro modo de fallo a descartar en el mismo router, porque se parece pero no tiene nada que ver con la codificación. Un HALNy HL-GSFP en Turris OS HBS 6.2.4 se detectó, el puerto incluso cambió a inband/1000base-x, y luego el enlace cayó y eth2 quedó abajo.
Causa: ese stick es en realidad un pequeño ordenador. Tarda algo así como un minuto en levantar su propio firmware, y solo después de eso responde a la jaula con algo sensato. Un arranque en frío hace que el router mire dentro de la jaula mucho antes de ese punto, así que la detección falla y la caja vuelve silenciosamente al WAN de cobre. Alargar el retardo de arranque lo arregló:
Sesenta segundos en vez de los tres por defecto, y otra persona con el mismo stick lo confirmó. Dos cosas más que ayudaron: desconectar el cable WAN de cobre y reiniciar de nuevo, y entrar al propio módulo para ver en qué estado está, por serie a 38400 8N1 o por SSH en 192.168.77.154 puerto 22666.