Quais checksums da EEPROM precisam ser recalculados depois de editar vendor name e PN em uma imagem SFP
Trabalho de bancada: recodificando um lote pequeno de módulos SFP+ para carregarem a vendor string e o part number que o equipamento do cliente espera. A edição em si é trivial em um editor hex, a escrita passa, a releitura bate byte a byte com o que gravei - e mesmo assim o host joga o módulo fora.
- módulos SFP+ genéricos, página A0 editada na mão
- programador baseado em CH341 com a ferramenta que veio junto
- campos editados: vendor name e vendor part number, nada mais tocado
- um dump intocado gravado de volta no mesmo módulo funciona bem, então o caminho de escrita em si não é o problema
O que comparei depois da edição:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorEntão os bytes de soma claramente não se moveram quando o payload se moveu. Antes de eu sair escrevendo minha própria ferramenta para isso: quais faixas de bytes essas duas somas realmente cobrem, são somas aditivas simples ou algo no formato CRC, e existe algum utilitário mantido que as recalcula para eu não fazer aritmética na mão em cada módulo?
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 4
Seu programador está fazendo o que ferramentas baseadas em CH341 normalmente fazem, que é nada. Elas gravam os bytes que você entrega e nunca tocam nos campos de checksum. Programadores de vendor recalculam na escrita, e é por isso que quem só usa esses nunca esbarra nisso e fica convencido de que o assunto inteiro é imaginário.
Duas coisas valem a pena confirmar antes de escrever qualquer ferramenta. Primeiro, o que releu a imagem depois da escrita - a mesma ferramenta que gravou, ou algo independente? Um leitor te servindo o próprio cache vai mostrar alegremente um byte que nunca chegou no chip. Segundo, você calculou a soma sobre os bytes 0 a 62 da imagem editada e comparou com o byte 63, ou está só comparando o byte 63 contra o dump original? Inalterado e correto não são o mesmo teste, e suas notas só mostram o primeiro.
Também vale nomear o host que rejeita. Alguns leem os campos de identidade e não verificam nada, outros validam de forma estrita e derrubam o módulo no instante em que uma soma está errada. Mesma imagem, veredito diferente.
São duas, e são somas burras de 8 bits, sem CRC envolvido em lugar nenhum.
Vendor name e vendor PN moram os dois na área base, então sua edição invalidou o CC_BASE enquanto o CC_EXT continuou legitimamente correto. Edições de serial number e date code atingem a faixa estendida em vez disso, e aí é o byte 95 que fica desatualizado. Recalcular qualquer um dos dois é duas linhas sobre o buffer: soma a faixa, mascara com 0xFF, guarda no byte de soma.
Se você preferir não fazer isso na mão, existe ferramenta pronta. O py-sfp-eeprom constrói e valida imagens de EEPROM a partir do Python (
python3 -m sfp_eeprom), e osfppiroda em um Raspberry Pi, checa as somas e se oferece para corrigi-las. Qualquer um dos dois é hábito melhor do que editor hex mais aritmética mental, porque o modo de falha é silencioso - o módulo relê exatamente como você gravou e só o host reclama.Acertar as duas somas do MSA é necessário e, dependendo em que porta de quem você está plugando, não suficiente.
A Cisco é o exemplo mais batido: a checagem de identidade não é só as strings. Alguém descobriu anos atrás que o valor que um módulo codificado Cisco carrega pode ser reproduzido com nada mais exótico que
xxd -r -p | md5sum, alimentado com o byte de código de vendor e depois os bytes do nome. Nesses dumps código e nome estão amarrados um ao outro - Finisar fica atrás do 02, Methode atrás do 0E. Deixe os dois discordarem e um Catalyst 2960X cospe o módulo de volta, com ou sem comandos de unlock.Normalmente é por isso que um dump copiado de um módulo funcionando para de funcionar assim que alguém cola uma vendor string diferente nele. As somas estão certas, a identidade é que deixou de ser autoconsistente.
Pequena correção ao enquadramento "conserta as duas somas e pronto": isso vale para os campos do MSA, não para a ideia de cada vendor do que é uma imagem válida.
A HP é o contraexemplo de sempre. Edite o serial number em uma imagem J4858B, bytes 68 a 83, e os bytes 124 a 127 de A0 mudam também - um checksum de vendor sentado depois dos bytes CC_BASE e CC_EXT do MSA. Aquilo foi remoído à exaustão e ninguém nunca publicou o algoritmo; as pessoas confirmaram que os bytes importam e o tópico terminou aí. Mesma história relatada em torno do J4859C e do J9150A. Equipamentos HP e Aruba mais recentes migraram para um esquema de challenge response (HPIDv2), que você não consegue forjar em uma EEPROM de jeito nenhum.
Então antes de investir em ferramenta, descubra o que o host de destino valida: duas somas aditivas para um host simples, uma identidade internamente consistente para Catalyst, e em algumas peças HP um campo não documentado que você não vai conseguir reproduzir.