Un ODI DFP-34X-2C2 en un Turris Omnia solo enlaza en 1000base-x, ethtool no acepta speed 2500
Cambié el ONU del ISP por un stick GPON ODI DFP-34X-2C2 en mi Turris Omnia para que la fibra termine en el router en vez de en otro equipo del estante. Esa parte funcionó: la línea está registrada, el tráfico fluye, sin quejas. El problema es la tasa. Nunca sube de 1Gbps, y 2.5G era la razón entera por la que compré este stick.
- Turris Omnia, TurrisOS 6.0.4
- stick GPON ODI DFP-34X-2C2 en la jaula SFP, eth2
- WAN de cobre desconectado, la jaula es dueña del puerto
Lo que dice el kernel después de un arranque, y lo que pasa cuando intento forzar la tasa:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 con el enlace arriba muestra el módulo como 1000baseX/Full y nada más alto, y el rechazo de arriba es ethtool diciéndome que speed 2500 no se puede anunciar.
Probado hasta ahora:
- entré por telnet al stick y fijé la tasa desde su propio shell; acepta el comando y luego vuelve a 1Gbps
- reinicios con y sin el WAN de cobre conectado
- revisé dmesg buscando algo sobre que el MAC recibiera oferta de 2.5G, no hay nada
¿Es el router limitando el puerto, o el módulo mismo? ¿Y hay algo del lado del host que haga que eth2 suba a 2500base-x con este stick?
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 5
El techo aquí es el módulo mismo, no el Omnia.
Lo que el host negocia es lo que la EEPROM del módulo declara que puede hacer, porque en el momento de la detección ese chip es lo único con lo que la jaula tiene que trabajar. En ese stick está codificado para 1000Mbps. Así que el puerto se configura como inband/1000base-x, no hay ningún modo 2500base-x para que phylink lo ofrezca, y ethtool rechaza speed 2500 porque no hay nada con lo que anunciarlo. Ningún interruptor del lado del host evita eso: ethtool solo puede pedir modos que se le dijo al puerto que existen. El shell dentro del stick configura el lado PON del módulo, no lo que la jaula anuncia hacia el MAC, que es exactamente por qué tu cambio por telnet se evapora y vuelves a caer en 1Gbps.
Eso deja dos opciones reales: que se recodifique el módulo para que anuncie 2.5G, o reemplazarlo por uno que ya lo haga. Si vas por la ruta de recodificar, ten un repuesto en el escritorio. Estás reescribiendo la página de identidad en la que confía el host, y un byte equivocado ahí te deja con un módulo que la jaula deja de reconocer del todo. Además mantén las dos tasas separadas en tu cabeza, lo que entrega el lado PON y lo que negocia el enlace SFP-a-MAC son números distintos, así que calcula qué ganas realmente antes de gastar dinero en esto.
Antes de culpar al stick, comprueba qué device tree arranca el equipo. La jaula en un Omnia no es una interfaz adicional: ella y la mitad WAN metálica son dos frentes hacia una misma eth2, y solo uno de los dos está conectado realmente al MAC a la vez. Cuál de los dos sea depende del dtb que carga el kernel al arrancar. Así que mira a qué apunta /boot/dtb: si no es armada-385-turris-omnia-sfp.dtb, estás mirando el lado de cobre y los números no significan nada.
Publica también el dmesg | grep -i sfp completo, no solo la línea de mvneta. Lo que el kernel lee del módulo en el momento de la detección es la parte interesante aquí, y normalmente resuelve la pregunta en una línea.
El dtb ya es el de SFP, hice un symlink a armada-385-turris-omnia-sfp.dtb cuando puse el stick por primera vez, de lo contrario nada subía en absoluto. La jaula es dueña de eth2 y el WAN de cobre se queda desconectado.
dmesg | grep -i sfp muestra el módulo identificado y luego la misma línea que publiqué, eth2 switched to inband/1000base-x link mode. Nada sobre 2500 en ningún lado. ethtool eth2 reporta 1000baseX/Full mientras el enlace está arriba y pasando tráfico, y ethtool -s eth2 speed 2500 sigue devolviendo Invalid argument, así que no lo va a anunciar en absoluto. Fijar la tasa por telnet dentro del stick se comporta igual que antes, la acepta y luego cae de vuelta a 1Gbps.
Historia relacionada de la misma placa, por si alguien llega aquí con un stick que no sube en absoluto en vez de uno atascado en 1G. HALNy HL-GSFP en un Omnia en Turris OS HBS 6.2.4: el kernel lo identificó, el puerto incluso pasó a inband/1000base-x, y luego el enlace cayó y eth2 nunca subió.
Ese no es un problema de EEPROM. Hay todo un pequeño sistema operativo viviendo dentro de ese stick, y quiere alrededor de un minuto para sí mismo antes de estar en condiciones de responder al host. En un arranque en frío el router ya probó la jaula y se rindió mucho antes de ese punto, así que el puerto vuelve a la magnética de cobre. Alargar el retraso de U-Boot lo arregló aquí:
El valor por defecto es 3 segundos; a 60 el stick ya terminó de subir para cuando el kernel llega a probar la jaula. Desconectar el WAN de cobre y reiniciar una segunda vez también ayudó a la detección. Y si alguna vez necesitas mirar dentro de un stick, el serial es 38400 8N1.
De acuerdo con el diagnóstico, con una advertencia para quien llegue aquí con un síntoma parecido. No todo "no hace 2.5G" en esta placa es el módulo. Hubo un snapshot de OpenWrt donde se retroportó el código genérico de validación de phylink, y rompió la jaula del Omnia por completo: ethtool seguía anunciando 2500baseX/Full pero reportaba Link detected: no. Revertir ese retroporte devolvió el puerto a como estaba, ethtool leyendo Link detected: yes, 2500Mb/s full duplex, y un pull request posterior arregló el retroporte en el proyecto original.
La pista está en lo que ethtool lista como soportado y anunciado. Si 2500baseX/Full está ahí y el enlace simplemente se niega a subir, mira el kernel y phylink después de tu última actualización de imagen, no el óptico. Si, como aquí, el puerto solo conoce 1000baseX porque eso es lo que el módulo declaró sobre sí mismo, ningún software del host va a conjurar el modo. Eso es el byte de tasa de bits nominal en la EEPROM haciendo exactamente lo que dice SFF-8472 que debe hacer.