El stick GPON DFP-34X-2C2 aparece en dmesg solo tras decenas de segundos y luego enlaza a 1G
Estoy reemplazando la ONT del operador por un stick SFP GPON en la máquina Linux que termina nuestro WAN, y el stick no se comporta en absoluto como un transceptor. Lo insertas y la jaula queda en silencio durante medio minuto o más, tanto que dos veces asumí que el módulo estaba muerto, y cuando el kernel por fin lo nota, el enlace se estabiliza a velocidad gigabit, lo cual anula el propósito del ejercicio.
El banco de pruebas:
- máquina router Linux, jaula SFP manejada por la capa SFP del kernel, kernel mainline
- stick GPON ODI DFP-34X-2C2
- un stick Huawei MA5671a como segunda muestra
- un módulo de fibra 1G normal que aparece al instante en la misma jaula, así que la jaula en sí está bien
$ 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 offProbado hasta ahora:
- reasentar el stick y dejarlo tranquilo varios minutos antes de tocar la interfaz, y la espera está ahí cada vez, no solo en la primera inserción
- reiniciar la interfaz después de la detección, lo cual no cambia nada del modo negociado
- el MA5671a muestra la misma aparición lenta, así que no es una sola muestra defectuosa
¿Es simplemente así como se comportan los sticks GPON en un host Linux, o mi lado está haciendo algo mal? ¿Qué está pasando realmente entre la inserción y la detección aquí?
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
Antes de que empiecen las conjeturas, hay dos cosas que vale la pena fijar. Primero, publica el dmesg completo desde la inserción en adelante en vez de un grep de dos líneas. Dices que la jaula está detrás de la capa SFP del kernel y no tengo motivo para dudarlo, pero las líneas que filtraste son las que muestran cuántas veces se sondeó el módulo, qué falló en el medio y cuánto duró cada intento.
Segundo, ¿qué dice la propia interfaz que puede hacer una vez que el stick finalmente está arriba, y aparece 2500baseX en algún lugar de los modos anunciados? ¿Y qué velocidad te está dando el ISP en el lado PON, porque si es un plan gigabit, entonces el enlace que obtienes es el correcto y no hay nada que arreglar.
Comportamiento esperado, lamentablemente, y no es tu host.
Un stick GPON no es un transceptor con un chip EEPROM dentro. Es una pequeña computadora Linux en su propio SoC, metida en una carcasa SFP, y la EEPROM que tu host lee por I2C está emulada por ese sistema. Nada responde en el bus hasta que el propio firmware del stick ha arrancado lo suficiente como para servir esas páginas, por eso te quedas ahí sentado decenas de segundos mientras un módulo normal responde de inmediato. Ese silencio antes de tu línea del módulo es el arranque.
La segunda mitad de tu problema es que lo que anuncian esas páginas emuladas suele estar simplemente mal. La interfaz del lado del host en estos sticks es 2500BASE-X, y la EEPROM dice otra cosa, así que la capa SFP se lo toma al pie de la letra y se asienta en el modo gigabit. Ambas mitades se resuelven en el kernel con excepciones específicas por módulo en lugar de algo configurable, y el DFP-34X-2C2 del OEM tiene una de esas excepciones precisamente por este motivo.
Que tu muestra caiga en ella depende de las cadenas de vendedor y de parte que reporta, y estas difieren entre las versiones rebautizadas, así que compara lo que imprime tu línea de dmesg con lo que coincide en la excepción antes de dar por hecho que estás cubierto.
Para subrayar por qué se necesita este enfoque de excepciones: SFF-8472 asume un dispositivo de memoria pasivo que responde dentro de los tiempos normales de I2C. Nada en él contempla un dispositivo que necesita medio minuto de arranque antes de poder hablar, así que un host que sigue el estándar tiene todo el derecho de rendirse con el módulo o de confiar en los bits de modo que finalmente lee.
El punto sobre las versiones rebautizadas de arriba es la trampa práctica. La coincidencia se hace por las cadenas de vendedor y de parte, así que el mismo stick físico vendido bajo otro nombre se salta la excepción por completo y vuelves a tener un enlace gigabit sin razón aparente. Y no construyas nada que dependa de que el módulo esté presente poco después del arranque, porque esa carrera es imposible de ganar aquí.
Esperar que los fabricantes de sticks arreglen el contenido de su EEPROM también es optimista. Cuando se plantearon estos problemas, ni siquiera los ISP grandes recibieron gran cosa de ellos.
El mismo tipo de problema aparece en routers de consumo, así que al menos estás acompañado. Los dueños del Archer BE800, BE900 y GE800 con un stick en el puerto combo SFP+ de 10G obtienen 1 Gbit/s en lugar de los 2,5 que pagan, y la propia lista de TP-Link de sticks reportados como funcionales en esos puertos es el ODI DFP-34X-2C2, el Huawei MA5671A y el Nokia G-010SA, que es la misma lista corta de piezas en la que todo el mundo termina.
El primer consejo ahí fue firmware más reasentar el módulo, y la parte del reasentado no es un sinsentido, un módulo que no ha hecho clic hasta el fondo de verdad se degrada. Las compilaciones beta terminaron exponiendo la configuración del puerto, una por modelo:
Con una de esas instalada, el modo del puerto SFP se vuelve configurable por telnet, con la interfaz caída primero,
ip link set eth1 downy así sucesivamente.Aun así sigue siendo una solución alternativa y no una corrección. Un año después llegaban las mismas quejas, y no solo sobre sticks: una persona tenía un AOC JT-AOC-SFP-15 de JT-COM en ese puerto, otra un DAC pasivo 10G SFP+ de Ampcom, y ambos se quedaban en 1 Gbit/s.
Vale la pena conocer el otro modo de fallo antes de que alguien sugiera pasar el stick a una NIC. En OpenWrt 19.07 sobre x86 con una Intel X520 y kmod-ixgbe, un MA5671a simplemente es rechazado como SFP no compatible. Poner allow_unsupported_sfp en los archivos habituales de configuración de módulos no hace absolutamente nada ahí, el parámetro hay que pasarlo al cargar el módulo:
Y aun con eso el driver lo sigue rechazando, porque la EEPROM del stick de entrada no describe un transceptor normal y la bandera no puede tapar eso. Si terminas usando una NIC, prueba el puerto primero con un módulo 1000BASE-T, LX o SX normal, porque si no estás depurando la tarjeta y el stick al mismo tiempo.
Cuidado con no juntar esas dos cosas, sin embargo. allow_unsupported_sfp vive dentro de ixgbe y decide si ese driver está dispuesto a manejar una óptica dada, lo cual es una decisión distinta de la que se toma aquí. La espera larga y el modo equivocado vienen de que la capa SFP genérica lee las páginas emuladas y pasa el resultado a phylink, y ahí es donde están las excepciones por módulo.
En una placa con una jaula SFP propiamente dicha, la bandera de ixgbe no existe y no es la solución, y en una X520 la lista de excepciones tampoco te va a rescatar. El mismo síntoma en la superficie, distinta capa por debajo, y confundirlas es como la gente termina reconstruyendo drivers para nada.
Otro límite que vale la pena trazar ya que estás en esto: que el host vea el stick y que la OLT lo acepte son problemas independientes, y el segundo puede ser mucho peor.
Hay un caso bien documentado de un Xicom DFP-34X-2C2 cargado con la identidad copiada de un ZTE ZXHN F601 usando setmac y consultas OMCI, número de serie GPON, contraseña PLOAM, LOID, número de serie de hardware y cadena de firmware, todo. El stick alcanza el estado O5 y luego simplemente se queda ahí, sin ID de ONU asignado y sin tráfico, porque llegar a O5 solo significa que el ranging funcionó, mientras que la carga del MIB todavía tiene que coincidir con el perfil de ONT que espera la OLT. Nadie en ese hilo produjo una solución.
Así que cuando sí logres 2500BASE-X en local, no des por hecho que lo difícil ya quedó atrás. Donde el operador ata un perfil de servicio a un modelo de ONT específico, puede que no exista ningún conjunto de campos copiados que haga aceptar un stick de terceros.