El Dell M14MK SFP28 es rechazado en OpenWrt sin modos de interfaz comunes, mientras un QSFPTEK SFP+ sí enlaza
Laboratorio doméstico pequeño. Flasheé un Linksys LGS328C a OpenWrt SNAPSHOT para alejarme de la interfaz web de fábrica. Todo sobrevivió a la migración salvo un puerto SFP28 que antes funcionaba perfectamente.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- módulo: Dell S28-10G-25G-SR-85C, tasa dual 10G/25G, el EEPROM lee DELL M14MK rev A1
- módulo de referencia en la misma jaula: QSFPTEK QT-SFP+-SR
- misma fibra y mismo extremo remoto en ambas pruebas
El módulo Dell se detecta y luego se descarta directamente:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noCosas que ya comprobé:
- cambié al SFP+ de QSFPTEK en la misma jaula: el log muestra que el puerto elige inband/10gbase-r, y obtengo un enlace limpio de 10 Gbps;
- el mismo módulo Dell funcionó bien en este switch bajo el firmware de fábrica, así que la óptica no está muerta;
- lo reasenté y limpié el conector, sin cambio en el log.
¿Está el módulo realmente mal programado, o el driver del switch se está poniendo quisquilloso con una pieza capaz de 25G? Preferiría entender esto en vez de simplemente comprar otra óptica.
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
Ese volcado lo explica todo. La capa sfp del kernel tiene exactamente una entrada para decidir qué modos de interfaz puede correr un módulo, y son esos bytes de conformidad. Sin ninguno activado, termina con un conjunto vacío, lo cruza con lo que ofrece el MAC, no obtiene nada en común, e imprime exactamente el mensaje que estás viendo. El 10000baseCR/Full en ethtool es lo que queda del lado del puerto, no algo que el módulo haya pedido. Al firmware de fábrica no le importa, porque esas imágenes generalmente se saltan por completo los bytes de conformidad y en su lugar comparan las cadenas de fabricante y pieza contra una lista fija - por eso la óptica funcionaba antes de que flasheases.
El arreglo que realmente se sostiene es una excepción (quirk) de módulo. En drivers/net/phy/sfp.c añade una entrada SFP_QUIRK_S que coincida con el fabricante DELL y la pieza M14MK y fuerce ETHTOOL_LINK_MODE_10000baseSR_Full y PHY_INTERFACE_MODE_10GBASER, luego reconstruye la imagen. El puerto sube como un enlace 10G normal reportando 10000baseSR/Full y la línea de módulo no soportado desaparece del log.
Dos advertencias. Mantén el parche en una forma que puedas enviar a netdev en vez de guardarlo en tu propia rama: el EEPROM no se va a arreglar solo y otras personas tienen la misma pieza Dell. Y si prefieres no mantener nunca una build de kernel, la alternativa aburrida es el SFP+ de QSFPTEK que ya tienes - 10G es de todos modos lo máximo que este puerto te va a dar.
Antes de culpar al driver del switch, vuelca el EEPROM y mira qué declara el módulo:
ethtool --module-info lan28. Publica las primeras filas del volcado hexadecimal más elethtool lan28completo. "no common interface modes" significa que el kernel no pudo derivar ni un solo modo utilizable del módulo, así que el contenido de esos bytes es toda la historia aquí.Otra cosa que confirmar: ¿el QSFPTEK está en la misma jaula, no en una vecina? Tu línea de log dice p49 mientras que la salida de ethtool dice lan28, y confundir puertos en este tipo de prueba hace perder mucho tiempo.
Lo volqué. Versión corta: no hay ningún código de conformidad 10G activado en absoluto - esos bytes están simplemente vacíos, mientras que las cadenas de fabricante y pieza están rellenas exactamente como cabría esperar para un DELL M14MK rev A1.
ethtool lan28sigue mostrandoAdvertised link modes: 10000baseCR/FullyLink detected: no, ydmesg | grep lan25no muestra nada más allá de las dos líneas de mi primer mensaje.Así que el módulo prácticamente no le dice nada al host sobre lo que realmente puede hacer, y el QSFPTEK en la misma jaula sigue enlazando a 10 Gbps.
Vale la pena dejarlo por escrito, porque el reporte de bug anterior sobre exactamente esta combinación lo adivinaba de otra forma. La teoría ahí era que el módulo de tasa dual anuncia 25gbase-r, el driver rtl930x no implementa ese modo, la intersección sale vacía y no hay nada malo con el módulo en sí. El volcado hexadecimal descarta esa explicación: el módulo no anuncia nada, no 25G. Mismo mensaje del kernel, causa distinta, y solo el volcado distingue las dos.
También es un recordatorio de que una óptica de marca no está automáticamente codificada correctamente. El propio OS10 de Dell mostrará un Q28-128GFC-SW4 genuino (pieza KP0VM) como QSFP28 100GBASE-SR4 con Qualified false, porque algunos lotes llevan una codificación de EEPROM que su calificación de medio no reconoce, y el enlace FC se queda caído hasta que permites transceptores no soportados a mano.
Construí una imagen con la entrada SFP_QUIRK_S para DELL / M14MK y hace exactamente lo que describiste. El puerto enlaza a 10 Gbps,
ethtool lan28ahora reporta 10000baseSR/Full con el enlace activo, y el log está limpio - sin ninguna línea de módulo no soportado en ningún sitio. Lo dejé corriendo con tráfico real durante unos días antes de tocar nada más en la caja, sin parpadeos.Ahora estoy limpiando el parche para enviarlo a netdev, ya que mantenerlo en mi propio árbol no ayuda a nadie. Gracias por empujarme primero hacia el volcado de module-info, había estado leyendo las tablas de modos del driver durante dos noches.