Recodificación de EEPROM: contraseñas y mecánica

La idea clave tras años de discusión técnica: la compatibilidad de los transceptores no es firmware — son cadenas de identificación en la EEPROM, leídas por I²C. Un conmutador rechaza un módulo simplemente porque no reconoce la cadena de fabricante. Ese único hecho explica la práctica habitual de «codificar todo como Cisco — funciona casi en todas partes» y todo el mercado de herramientas de codificación.

Dónde residen las contraseñas

Escribir en áreas protegidas de la memoria del módulo requiere una contraseña de 4 bytes introducida en una dirección fija antes de la escritura:

Contraseñas mencionadas con frecuencia

Algunos módulos QSFP-DD de ciertos fabricantes se entregan con sus propios valores fijos por defecto, y algunos módulos basados en microprocesador usan una contraseña variable que cambia — una trampa para quien intente la fuerza bruta.

Por qué la fuerza bruta no es la respuesta

Una contraseña de nivel de fabricante que protege todo el mapa de memoria tarda del orden de más de 100 días en romperse por fuerza bruta; incluso una contraseña ASCII de nivel de host tarda hasta unos tres días. La vía práctica es una base de datos de códigos y contraseñas conocidos capturados de módulos originales — ahí es donde está el verdadero valor de una herramienta de codificación, no en el hardware I²C (que es simple).

Trampas de los programadores de bricolaje

• Los programadores CH341A baratos no calculan la suma de comprobación de SFP. Escribir una imagen sin un CC_BASE/CC_EXT válido produce un módulo que el conmutador rechazará. Se necesita una herramienta que recalcule las sumas de comprobación automáticamente.
• Algunos conmutadores solo escriben en la dirección 0x50, así que la contraseña en 0x51 no se puede alcanzar desde el propio conmutador — se necesita una placa programadora adecuada.
• El pin de protección de escritura de la EEPROM — algunas fábricas unen WP a Vcc, de modo que el módulo queda bloqueado contra la escritura en campo.

Casos de campo

• Módulos codificados como un fabricante no autonegociaban en un conmutador de otro; recodificados con la cadena de fabricante del propio conmutador, se establecieron de inmediato.
• Algunos fabricantes de óptica entregan módulos sin codificar de forma deliberada, esperando que el comprador los codifique para la plataforma de destino.
• Los módulos DWDM se sintonizan a la longitud de onda a través de la misma interfaz de gestión que se usa para la codificación.

Cómo hacerlo en CodingBox

1. Lea el módulo; se guarda automáticamente en la base de datos de códigos y se toma una copia de seguridad antes de cualquier escritura.
2. Configure la dirección de tabla, la dirección de contraseña y el valor de la contraseña en Memoria protegida y contraseñas — las contraseñas conocidas de la base de datos se aplican automáticamente.
3. Edite el fabricante, el número de pieza y otros campos de identidad en el editor de EEPROM. CC_BASE y CC_EXT se recalculan por usted.
4. Escriba las páginas seleccionadas y luego vuelva a leer para verificar. Compruebe el módulo en el conmutador con los comandos de Verificación de la óptica.

Codifique módulos solo para la interoperabilidad a la que tiene derecho, y siga las políticas de su organización y de los fabricantes.

Las reglas detrás de una recodificación limpia — formatos de campo, qué bits fijar y qué sumas corregir — están en Campos de fabricante, Códigos de cumplimiento y Sumas de comprobación.

Qué hace la fábrica en el mismo paso, y qué áreas contienen calibración que una escritura descuidada puede destruir: Fabricación y pruebas, Controlador y firmware.

Qué contiene cada byte antes de editar: Mapa A0h de SFF-8472, Mapa de página superior de SFF-8636, Mapa de páginas superiores de CMIS, Mapa XFP.

Números de pieza de destino y su gramática por fabricante: Números de pieza OEM; qué comprueba cada clase de plataforma tras la escritura: Cómo valida cada NOS un módulo.