O programador lê o SFP+ FTLX8571D3BCV-IT, mas responde No Acknowledge na escrita
Mantenho um pequeno fundo de troca de módulos: os nós estão espalhados pela cidade, e para quase cada switch de terceiros preciso recodificar o SFP. Com módulos gigabit o esquema já está rodado há muito tempo, mas travei no de dez gigas.
O que está na bancada:
- programador com cage para SFP/SFP+, alimentação de 3.3 V
- Finisar FTLX8571D3BCV-IT e FTLX1471D3BCV-IT, os dois leem
- Cisco GLC-LH-SM de estoque antigo
- HP J4858B e J4859C
A leitura sai estável e repetível, os dois bancos inteiros. A escrita não vai em nenhuma variante:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeO que já verifiquei:
- as mesmas operações em SFPs gigabit comuns com o mesmo programador passam, então o circuito e a alimentação estão vivos;
- peguei um segundo exemplar do FTLX8571D3BCV-IT, o comportamento é idêntico byte a byte;
- no GLC-LH-SM o No Acknowledge chega na hora, ainda antes de tentar tocar nos campos do fabricante.
Então não é uma questão do exemplar específico. Isso é proteção de escrita por hardware no próprio módulo, ou no SFP+ a memória já não é mais uma EEPROM pura e uma escrita comum via I2C simplesmente não chega lá? E separadamente me interessa o HP J4858B/J4859C: alguém escreve eles com um programador comum, ou isso é um beco sem saída conhecido?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
Aqui se misturaram dois mecanismos diferentes, e eles se resolvem de jeitos diferentes.
O primeiro é uma EEPROM comum com proteção de escrita por hardware. O chip de memória tem um pino write protect, e enquanto ele está puxado, a leitura funciona e a escrita cai fora. O jeito que as pessoas que mexeram nisso de perto recomendavam é aterrar esse pino durante a gravação. Em parte dos módulos gigabit isso já basta.
O segundo é o que você encontrou no de dez gigas. No SFP+ os dados frequentemente não ficam numa EEPROM separada, mas atrás do microcontrolador do módulo: ele mesmo entrega A0 e A2 para leitura e só aceita escrita com a própria sequência de comandos. Um programador padrão não conhece essa sequência e recebe No Acknowledge em qualquer tentativa, independente de qual campo você está mirando. Ali não tem o que aterrar.
O que realmente ajuda a contornar a cage: soldar fios direto nos pinos 4 e 7 do módulo, ou seja, nas linhas I2C, driblando o conector do programador. Pelos relatos, depois disso escreve parte dos módulos que ficavam mudos na cage. É um método bruto, precisa de mão firme, e depois disso o módulo vive por sua conta e risco.
HP é uma história à parte. Programadores padrão não pegam eles, é preciso um tratamento próprio, e no J4858B/J4859C com o circuito comum eu não esperaria sucesso. Se a tarefa é só conseguir um módulo funcional num switch de terceiros, sai mais barato não sofrer com HP e pegar um módulo com memória honesta e gravar nele a imagem do fabricante inteira: dos 256 bytes do dump, os primeiros 128 são significativos, o resto é reserva do fabricante.
Nenhum fabricante, claro, dá suporte a esse tipo de recodificação: com um módulo reprogramado não há com o que ir ao suporte.
Esclarece duas coisas, senão vai virar chute. O No Acknowledge chega já no endereço do dispositivo, ou só depois do primeiro byte de dados? Pelo log do programador isso normalmente dá para ver. E que programador é o seu - um aparelho pronto ou uma montagem caseira com circuito próprio? Disso depende o que esperar dos 3.3 V na cage.
Também é interessante o comportamento ao ligar a alimentação: a falha é a mesma logo depois de instalar o módulo e depois de ele ficar alguns minutos energizado? E os quatro tipos se comportam igual, ou Finisar e HP são diferentes: o HP normalmente tem motivos próprios de falha, é melhor separar eles do resto desde já.
Reportando o resultado. Soldei nas linhas I2C direto nos pinos 4 e 7, driblando a cage. Os Finisar foram: o FTLX8571D3BCV-IT gravou e foi confirmado por leitura reversa, o FTLX1471D3BCV-IT também. O GLC-LH-SM parou de devolver No Acknowledge e grava normalmente.
O HP não se rendeu. O J4858B formalmente aceita a escrita, mas depois da edição o módulo é rejeitado pelo switch, o J4859C se comporta do mesmo jeito. Então para mim a questão está resolvida pela metade: Finisar e Cisco eu já gravo, HP deixei de lado até tempos melhores.
Com o HP a armadilha é mais profunda que proteção de escrita, então o seu resultado era esperado. No J4858B, ao editar os bytes 68-83, ou seja, o número de série, muda o checksum nos bytes 124-127, e depois disso o módulo é rejeitado. Isso não é o CC_BASE e o CC_EXT do MSA, que não é problema calcular, é um checksum próprio do fabricante nos últimos quatro bytes do A0. O algoritmo nunca foi decifrado publicamente, por mais que mexessem nele.
O J9150A é da mesma história. E em módulos mais novos da HP e da Aruba eles saíram de vez do checksum estático para um esquema de desafio-resposta, o HPIDv2, e ali o programador é inútil em princípio. Então "grava, mas não é aceito" é exatamente o que deveria ter acontecido.
Já que você tem um parque, não um módulo só, vou falar da ferramenta. Para recodificação para Huawei S5731 e S6730 e para HP 6120XG eu adaptei o UACC-SFP-WIZARD da Ubiquiti - como programador barato ele está bem vivo. Só que sobre os próprios módulos Ubiquiti circulam listas de senhas, entradas do tipo 0x00001011, SFPX, QSFP, e sem elas parte dos módulos não abre para escrita. Das imagens eu uso o FTLX8571D3BCV e o FTLX8574D3BCV, mais raramente o SNR-SFP+W73-3 e o W37-3.
Vou corrigir a generalização acima, para ninguém sair correndo para o ferro de solda antes da hora: nem todo SFP+ tem a memória escondida atrás de um microcontrolador. No meu caso, o FTLX8574D3BCV e um par de SNR-SFP+W73-3 gravaram com um programador comum na cage, sem nenhuma solda. Então primeiro vale a pena testar o exemplar específico, e só depois partir para o contorno.
Aterrar o pino write protect, aliás, também não é uma receita universal: num módulo com microcontrolador isso não dá em nada, ali a recusa vem do firmware do controlador, não da memória. Essa operação só faz sentido onde existe uma EEPROM separada e honesta, e precisa ser feita com o módulo desenergizado, senão é fácil transformar o módulo num tijolo.