Turris Omnia fija un stick XPON Luleey LL-XS2510 a 1000baseX y ethtool nunca ofrece 2.5G

Publica la salida completa de ethtool eth2 y las líneas de sfp del dmesg, no solo el mensaje de enlace. La parte interesante es qué decidió el host que el módulo es capaz de hacer: si phylink se asentó en inband/1000base-x, lo tomó de la propia EEPROM del módulo, y nada de lo que configures en el router va a añadir un modo que el driver nunca vio.

La jaula del Omnia está bien hasta 2.5G, así que el hardware no es lo que te está limitando aquí. Di también si cambió algo en el host recientemente, incluida una actualización de imagen.

dmesg, idéntico en cada arranque:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 da 1000baseX/Full tanto como conjunto supported como advertised, y Link detected: yes a 1000Mb/s full duplex. Nada por encima de 1G aparece en ninguna parte de la salida.

flash set LAN_SDS_MODE 6 en el stick sí se aplica y sobrevive a un reinicio del módulo, pero el lado del host no reacciona en absoluto: mismo mensaje, mismo 1G. El router ha estado en esta imagen desde que se instaló el stick, así que no hay nada a lo que hacer rollback.

Eso es el host tomando la palabra del módulo. El driver sfp lee la EEPROM, ve una pieza que declara 1000base-x, y fija eth2 en inband/1000base-x; phylink entonces no tiene ningún modo de 2.5G que ofrecer, que es exactamente la salida de ethtool que publicaste. Lo que configuras dentro del RTL960x con LAN_SDS_MODE toca el propio serdes del módulo, no lo que le anuncia al router, así que nunca iba a cambiar el modo negociado.

Dos salidas, y solo conozco estas dos. O reescribes la EEPROM del módulo para que anuncie 2.5G, que es el truco conocido en el DFP-34X-2C3, pero el tuyo es un 2C2 y yo no asumiría los mismos offsets. O parcheas el host: agrega un quirk para este módulo en sfp.c y corre un kernel con eso, dejando el stick intacto.

En balance yo parchearía el host. Una EEPROM inutilizada en un stick que no puedes reflashear fácilmente es una tarde mucho peor que un kernel al que puedes hacer rollback.

Otra razón para mantener al host bajo sospecha en vez de al módulo. En los snapshots de OpenWrt hubo un período en el que el código de validación de phylink genérico traído por backport rompió directamente la jaula SFP del Omnia: ethtool seguía anunciando 2500baseX/Full y el puerto simplemente reportaba Link detected: no. Se rastreó limpiamente hasta ese commit del kernel, quitar el backport devolvió el enlace a 2500Mb/s full duplex, y una corrección posterior lo cerró.

Síntoma distinto al tuyo, misma lección. En placas mvneta y phylink el software del host decide qué se le permite hacer a la jaula, y vale la pena mantener una imagen de buen estado conocido a la que volver antes de ponerte a construir la tuya.

Si al final vas por el camino del kernel personalizado en Turris OS, toma primero un snapshot: schnapps create "Before new kernel", luego opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk y reinicia. Si el kernel se porta mal, haces rollback en vez de desarmar el router.

Lo segundo que nadie menciona hasta después: un enlace de 2.5 Gbps no es 2.5 Gbps de tráfico. La CPU Armada del Omnia no va a empujar eso en una sola cola, así que planea el packet steering y el ajuste de RPS antes de que el número en el cable se convierta en throughput.

Una trampa sin relación para cualquier otro que lea esto con un stick distinto: algunos módulos PON corren su propio sistema operativo y necesitan más o menos un minuto antes de responder siquiera, así que en un arranque en frío el router sondea la jaula demasiado pronto y vuelve a la magnética de cobre. fw_setenv bootdelay 60 en U-Boot es la cura habitual. No es tu caso, ya que tu módulo se detecta de inmediato.

Cerrando el ciclo: el host parcheado ganó. Construí un kernel con el sfp.c modificado, tomé primero el snapshot con schnapps, instalé el ipk con --force-reinstall y reinicié. ethtool eth2 ahora lista 2500baseX/Full y el enlace sube a 2.5 Gbps.

Al módulo al final no se le hizo nada. LAN_SDS_MODE se quedó donde estaba y resultó ser irrelevante, así que nunca tuve que tocar la EEPROM.

El throughput también necesitó el segundo consejo. Justo después del reinicio el equipo se quedaba bastante por debajo de la velocidad del enlace en una sola cola; con el packet steering ajustado, el WAN por fin hace lo que se compró el stick para hacer.