CodingBox Q&A Ask question

El programador lee un SFP+ FTLX8571D3BCV-IT, pero al escribir responde No Acknowledge

Asked Active Viewed 110 AI translation from Русский
6

Mantengo un pequeño fondo de intercambio de módulos: los nodos están repartidos por la ciudad, y hay que recodificar la SFP para casi cada switch ajeno. Con los módulos de gigabit el procedimiento está resuelto desde hace tiempo, pero con uno de diez me atasqué.

Lo que hay en la mesa:

  • programador con jaula para SFP/SFP+, alimentación de 3,3 V
  • Finisar FTLX8571D3BCV-IT y FTLX1471D3BCV-IT, ambos se leen
  • Cisco GLC-LH-SM de existencias antiguas
  • HP J4858B y J4859C

La lectura se toma de forma estable y repetible, ambos bancos enteros. La escritura no funciona en ninguna variante:

read  A0 0x00-0xFF ... OK
read  A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledge

Lo que ya comprobé:

  • las mismas operaciones en SFP de gigabit normales con el mismo programador pasan sin problema, así que el cableado y la alimentación están vivos;
  • tomé un segundo ejemplar del FTLX8571D3BCV-IT, el comportamiento es idéntico byte a byte;
  • en el GLC-LH-SM el No Acknowledge llega de inmediato, incluso antes de intentar tocar los campos del fabricante.

Resulta que no es un problema del ejemplar concreto. ¿Es una protección de escritura por hardware en el propio módulo, o en el SFP+ la memoria ya no es una EEPROM desnuda y una escritura I2C normal simplemente no puede llegar ahí? Y aparte me interesa lo de HP J4858B/J4859C: ¿alguien los escribe con un programador normal, o es de antemano un callejón sin salida?

Comments 6

Accepted answer

Aquí se mezclan dos mecanismos distintos, y se resuelven de forma diferente.

El primero es una EEPROM normal con protección de escritura por hardware. El chip de memoria tiene un pin write protect, y mientras esté en alto, la lectura funciona y la escritura falla. El método que recomienda la gente que se ha dedicado a esto a fondo es poner ese pin a tierra durante el flasheo. En parte de los módulos de gigabit eso basta.

El segundo es con lo que te topaste en el de diez. En el SFP+, los datos a menudo no están en una EEPROM separada, sino detrás del microcontrolador del módulo: él mismo entrega A0 y A2 en lectura y solo acepta escritura con su propia secuencia de comandos. Un programador estándar no conoce esa secuencia y recibe No Acknowledge en cualquier intento, independientemente de a qué campo apuntes. Ahí no hay nada que poner a tierra.

Lo que realmente ayuda a saltarse la jaula: se sueldan cables directamente a las patas 4 y 7 del módulo, es decir, a las líneas I2C, esquivando el conector del programador. Según los reportes, después de eso se logra escribir en parte de los módulos que en la jaula se quedaban mudos. Es un método tosco, hacen falta manos firmes, y el módulo después de eso vive bajo tu propia responsabilidad.

HP es harina de otro costal. Los programadores estándar no los aceptan, ahí hace falta un manejo propio, y en el J4858B/J4859C con el cableado habitual yo no esperaría éxito. Si la tarea es simplemente conseguir un módulo funcional en un switch ajeno, sale más barato no torturar el HP y en cambio tomar un módulo con memoria honesta y volcarle la imagen del fabricante entera: de los 256 bytes del volcado, los significativos son los primeros 128, el resto es reserva del fabricante.

Desde luego, ningún fabricante da soporte a ese tipo de recodificación: con un módulo reflasheado no hay nada que llevar a soporte.

3 Russialambdaops44RU Show original (Русский) AI translation

Aclara un par de cosas, si no será adivinar. ¿El No Acknowledge llega ya en la dirección del propio dispositivo o después del primer byte de datos? En el log del programador eso normalmente se ve. ¿Y qué programador tienes: un dispositivo comercial o algo casero con su propio cableado? De eso depende qué esperar de los 3,3 V en la jaula.

También interesa el comportamiento al aplicar alimentación: ¿el rechazo es igual justo después de poner el módulo que después de que lleve un par de minutos con energía? ¿Y los cuatro tipos se comportan igual, o Finisar y HP se diferencian? En HP normalmente hay causas de rechazo propias, mejor separarlas del resto de entrada.

3 RussiadwdmmonkRU Show original (Русский) AI translation

Informo del resultado. Me solduré a las líneas I2C directamente en las patas 4 y 7, esquivando la jaula. Los Finisar funcionaron: el FTLX8571D3BCV-IT se escribió y se confirmó con lectura inversa, el FTLX1471D3BCV-IT también. El GLC-LH-SM dejó de dar No Acknowledge y se escribe con normalidad.

Los HP no se rindieron. El J4858B acepta la escritura formalmente, pero después de la modificación el switch rechaza el módulo, el J4859C se comporta igual. Así que para mí la pregunta queda cerrada a medias: Finisar y Cisco ya los escribo, HP lo dejo aparcado para mejores tiempos.

1 KazakhstanlinkguruKZ Show original (Русский) AI translation

Con HP la trampa es más profunda que la protección de escritura, por eso tu resultado era esperable. En el J4858B, al modificar los bytes 68-83, es decir, el número de serie, cambia el checksum en los bytes 124-127, y el módulo después de eso se rechaza. No son los CC_BASE y CC_EXT del MSA, esos no cuesta nada calcularlos, sino una suma propia del fabricante en los últimos cuatro bytes de A0. El algoritmo nunca se ha revelado públicamente, por mucho que se haya escarbado.

El J9150A es de la misma historia. Y en los módulos más nuevos de HP y Aruba directamente abandonaron la suma estática por un esquema de pregunta-respuesta, HPIDv2, y ahí el programador es inútil en principio. Así que «se escribe pero no se acepta» es exactamente lo que tenía que pasar.

1 Kazakhstanlambdaowl20KZ Show original (Русский) AI translation

Ya que tienes un parque y no un solo módulo, comento sobre la herramienta. Para recodificar para Huawei S5731 y S6730 y para HP 6120XG adapté el UACC-SFP-WIZARD de Ubiquiti; como programador barato está bastante vivo. Solo que sobre los propios módulos Ubiquiti circulan listas de contraseñas, entradas del tipo 0x00001011, SFPX, QSFP, y sin ellas parte de los módulos no se abre para escritura. De las imágenes que uso, FTLX8571D3BCV y FTLX8574D3BCV, con menos frecuencia SNR-SFP+W73-3 y W37-3.

3 Russiaportrunner91RU Show original (Русский) AI translation

Corrijo la generalización de arriba, para que nadie agarre el soldador antes de tiempo: no en todo SFP+ la memoria está escondida detrás de un microcontrolador. Yo tengo un FTLX8574D3BCV y un par de SNR-SFP+W73-3 que se escribieron con un programador normal en la jaula, sin ninguna soldadura. Así que primero conviene comprobar el ejemplar concreto, y solo después meterse en el rodeo.

Por cierto, poner a tierra el pin write protect tampoco es una receta universal: en un módulo con microcontrolador no da ningún resultado, ahí el rechazo no viene de la memoria sino del firmware del controlador. Esa operación solo tiene sentido donde hay una EEPROM separada honesta, y hay que hacerla con el módulo sin alimentación, si no es fácil terminar con un ladrillo en vez de un módulo.

2 UkrainecoremonkUA Show original (Русский) AI translation
Log in to comment. Log in