Qué calcula el Catalyst 2960X en el volcado del SFP: código de vendedor, nombre y MD5, y por qué falla una copia del volcado
Mantengo una red de operador, el parque de módulos es mixto, así que regularmente tengo que preparar módulos para switches específicos. Quiero por fin entender la mecánica de la verificación, en lugar de probar volcados al azar.
Con qué trabajo:
- Cisco Catalyst 2960X-24PS-L, el más exigente del parque
- QTECH QSW-3750-28TX-AC y D-Link DGS-3420, en ellos los mismos módulos suben sin problema
- módulos SNR-SFP+SR y SFP-10G-BX
En el volcado del módulo que el Catalyst sí acepta, al inicio veo el byte de código de vendedor seguido del nombre en ASCII:
0E 43 49 53 43 4F ...Lo que probé: saqué un volcado del módulo que sí sube en el C2960X-24PS-L, y reescribí en otro módulo solo el nombre de vendedor de ese volcado. En el QTECH y en el D-Link después de eso todo sube, pero el Catalyst no acepta ese módulo, aunque los bytes corregidos coincidan uno a uno con el donante.
De ahí mi pregunta sobre el mecanismo de verificación. ¿Qué calcula exactamente Cisco y sobre qué bytes, dónde se guarda el resultado en el módulo, y por qué no basta con el nombre de vendedor reescrito a partir de un volcado que sí funciona? Me interesa la lógica, el resto lo resuelvo yo solo.
Comments 6
La mecánica ahí es simple y ya está bien estudiada. No se verifica un campo aislado, sino un conjunto: el byte de código de vendedor más los bytes del nombre de vendedor. De esa secuencia se calcula un MD5, y el resultado se guarda en el propio módulo; el switch calcula lo mismo y lo compara.
Se reproduce con utilidades estándar, no hace falta nada especial:
Sustituyes tu código y tu nombre de vendedor y obtienes el valor que debería estar guardado en el módulo. De los códigos que realmente aparecen en los volcados: 02 - Finisar, 0E - Methode, el 11 aparece con frecuencia, pero nunca se llegó a identificar de quién es. Si el par código-nombre es consistente y el hash le corresponde, el módulo pasa en el C2960X-24PS-L.
Sobre lo anterior: muestra qué hay realmente guardado en el receptor. ¿Qué byte de código de vendedor quedó ahí y qué nombre está al lado? Por la descripción, parece que trasladaste el nombre pero dejaste el código o el propio hash del módulo original, y entonces el conjunto se desalinea, y el Catalyst lo rechaza con toda razón. Revisa las tres cosas juntas, no solo el campo que se ve en la salida del switch.
Lo revisé, todo coincide con tu versión. En el donante está 0E y luego CISCO, y en el receptor efectivamente reescribí el nombre, pero el código de vendedor quedó el original, y el hash también quedó el viejo. Corrí ambas combinaciones por xxd -r -p y md5sum: en el donante el valor coincide con lo que hay en el módulo, en el mío armado a mano no.
O sea que hay que trasladar el conjunto completo, no campo por campo. Ahora al menos está claro dónde mirar y qué comparar antes de poner el módulo en el puerto.
Una consecuencia importante que siempre se olvida: si el código de vendedor y el nombre no están alineados, el módulo no pasará en el Catalyst ni siquiera cuando el switch tiene permitidos los módulos no soportados. Justo por eso los volcados ajenos funcionan a veces sí y a veces no: se corrigieron a medias, y la verificación mira el conjunto completo.
De ahí la conclusión práctica sobre el volumen: en un volcado de 256 bytes importan los primeros 128, después viene la zona del fabricante. No hace falta arrastrar toda la imagen, pero la primera mitad hay que trasladarla de forma consistente, incluyendo campos que no se ven a simple vista en la salida del switch.
Por cierto, no todo se resuelve con un volcado. En el Medick SFP-10G-BX no hay memoria, sino un microcontrolador C8051F392: emula A0 y A2 y bien puede tener una contraseña o una consulta de vendedor. Ahí puedes comparar el conjunto hasta el último byte - desde fuera simplemente no lo van a aceptar. De herramientas que uso realmente tengo el SNR SFP Writer y el SFPTotal Plus, y algunos colegas tienen equipos caseros basados en CH341.
Una pequeña corrección, para no confundir a quien llegue aquí más adelante. Ese MD5 no tiene nada que ver con los checksums de MSA: CC_BASE y CC_EXT de SFF-8472 se calculan con una simple suma de bytes y se recalculan al instante. La verificación de vendedor vive por encima de ellos y con sus propias reglas, y rechaza el módulo justo en el momento en que los checksums de MSA están perfectos - de ahí la sensación de que el volcado es correcto y el módulo igual no se acepta.
Cisco, dicho sea de paso, no es ni de lejos el peor caso: al menos la mecánica es comprensible y reproducible. Lo más difícil es HP y Aruba, donde la memoria se comporta de forma interactiva y exige claves - ahí ya no basta con volcados.