Recodificação de EEPROM: senhas e mecânica

A percepção central de anos de discussão de engenharia: a compatibilidade de transceptores não é firmware — são strings de identificação na EEPROM, lidas por I²C. Um switch rejeita um módulo simplesmente porque não reconhece a string do fabricante. Esse único fato explica a prática comum de “codificar tudo como Cisco — funciona em quase qualquer lugar” e todo o mercado de ferramentas de codificação.

Onde ficam as senhas

Gravar em áreas protegidas da memória do módulo exige uma senha de 4 bytes inserida em um endereço fixo antes da gravação:

Senhas comumente citadas

Os módulos QSFP-DD de alguns fabricantes vêm com seus próprios padrões fixos, e alguns módulos baseados em microprocessador usam uma senha variável que muda — uma armadilha para quem tenta força bruta.

Por que a força bruta não é a resposta

Uma senha de nível de fabricante que protege todo o mapa de memória leva da ordem de 100+ dias para ser quebrada por força bruta; mesmo uma senha ASCII de nível de host leva até cerca de três dias. O caminho prático é um banco de dados de códigos e senhas conhecidos capturados de módulos originais — e é aí que está o real valor de uma ferramenta de codificação, não no hardware I²C (que é simples).

Armadilhas dos programadores caseiros

• Os programadores CH341A baratos não calculam a soma de verificação do SFP. Gravar uma imagem sem um CC_BASE/CC_EXT válido produz um módulo que o switch vai rejeitar. Você precisa de uma ferramenta que recalcule as somas de verificação automaticamente.
• Alguns switches só gravam no endereço 0x50, então a senha em 0x51 não pode ser alcançada a partir do próprio switch — é necessária uma placa programadora apropriada.
• O pino de proteção contra gravação da EEPROM — algumas fábricas amarram o WP ao Vcc, de modo que o módulo fica travado contra gravação em campo.

Casos de campo

• Módulos codificados como um fabricante não faziam autonegociação em um switch de outro; recodificados com a string do próprio fabricante do switch, subiram imediatamente.
• Alguns fabricantes de ópticas enviam módulos sem codificação de propósito, esperando que o comprador os codifique para a plataforma de destino.
• Os módulos DWDM são sintonizados por comprimento de onda pela mesma interface de gestão usada para a codificação.

Fazendo isso no CodingBox

1. Leia o módulo; ele é salvo automaticamente no code database, e um backup é feito antes de qualquer gravação.
2. Defina o endereço da tabela, o endereço da senha e o valor da senha em Memória protegida contra gravação e senhas — as senhas conhecidas do banco de dados são aplicadas automaticamente.
3. Edite o fabricante, o número de peça e outros campos de identidade no EEPROM editor. O CC_BASE e o CC_EXT são recalculados automaticamente para você.
4. Grave as páginas selecionadas e depois leia de volta para verificar. Confira o módulo no switch com os comandos em Verificando ópticas.

Codifique módulos apenas para a interoperabilidade a que você tem direito, e siga as políticas da sua organização e dos fabricantes.

As regras por trás de uma recodificação limpa — formatos de campo, quais bits definir e quais somas corrigir — estão em Campos do fabricante, Códigos de conformidade e Somas de verificação.

O que a fábrica faz na mesma etapa, e quais áreas guardam a calibração que uma gravação descuidada pode destruir: Fabricação e testes, Controlador e firmware.

Qual byte guarda o quê antes de você editar: Mapa A0h do SFF-8472, Mapa da página superior do SFF-8636, Mapa das páginas superiores do CMIS, Mapa do XFP.

Números de peça de destino e sua gramática por fabricante: Numeração de peças; o que cada classe de plataforma verifica depois da gravação: Como cada NOS valida um módulo.