Quelles sommes de contrôle EEPROM faut-il recalculer après avoir modifié le vendor name et le PN dans une image SFP
Travail au banc : recodage d'un petit lot de modules SFP+ pour qu'ils portent la chaîne constructeur et la référence attendues par le matériel du client. La modification elle-même est triviale dans un éditeur hexadécimal, l'écriture passe, la relecture correspond octet par octet à ce que j'ai écrit - et l'hôte rejette quand même le module.
- modules SFP+ génériques, page A0 modifiée à la main
- programmateur basé sur CH341 avec l'outil fourni
- champs modifiés : vendor name et vendor part number, rien d'autre touché
- un dump non modifié réécrit sur le même module fonctionne bien, donc le chemin d'écriture lui-même n'est pas le problème
Ce que j'ai comparé après la modification :
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 errorDonc les octets de somme n'ont manifestement pas bougé alors que le contenu, si. Avant de me mettre à écrire mon propre outillage pour ça : quelles plages d'octets ces deux sommes couvrent-elles réellement, s'agit-il de simples sommes additives ou de quelque chose de type CRC, et existe-t-il un utilitaire maintenu qui les recalcule pour que je n'aie pas à faire le calcul à la main sur chaque module ?
Comments 4
Votre programmateur fait ce que font normalement les outils basés sur CH341, c'est-à-dire rien. Ils écrivent les octets qu'on leur donne et ne touchent jamais aux champs de somme de contrôle. Les programmateurs constructeur recalculent à l'écriture, ce qui explique pourquoi les gens qui n'utilisent que ceux-là ne rencontrent jamais ce problème et sont convaincus que tout ce sujet est imaginaire.
Deux choses valent la peine d'être vérifiées avant d'écrire un outil. D'abord, qu'est-ce qui a relu l'image après l'écriture - le même outil qui l'a écrite, ou quelque chose d'indépendant ? Un lecteur qui vous sert son propre cache montrera volontiers un octet qui n'a jamais atterri dans la puce. Ensuite, avez-vous calculé vous-même la somme sur les octets 0 à 62 de l'image modifiée et comparé cela à l'octet 63, ou comparez-vous uniquement l'octet 63 au dump d'origine ? « Inchangé » et « correct » ne sont pas le même test, et vos notes ne montrent que le premier.
Ça vaut aussi le coup de nommer l'hôte qui le rejette. Certains lisent les champs d'identité et ne vérifient rien, d'autres valident strictement et écartent le module dès qu'une somme est fausse. Même image, verdict différent.
Il y en a deux, et ce sont des sommes 8 bits toutes bêtes, aucun CRC nulle part.
Le vendor name et le vendor PN se trouvent tous deux dans la zone de base, donc votre modification a invalidé CC_BASE tandis que CC_EXT est resté légitimement correct. Les modifications du numéro de série et du code date touchent en revanche la plage étendue, et c'est alors l'octet 95 qui devient obsolète. Recalculer l'un ou l'autre tient en deux lignes sur le tampon : sommer la plage, masquer avec 0xFF, stocker dans l'octet de somme.
Si vous préférez ne pas coder ça vous-même, il existe de l'outillage. py-sfp-eeprom construit et valide des images EEPROM depuis Python (
python3 -m sfp_eeprom), etsfppitourne sur un Raspberry Pi, vérifie les sommes et propose de les corriger. L'un ou l'autre est une meilleure habitude qu'un éditeur hexadécimal plus du calcul mental, parce que le mode de défaillance est silencieux - le module se relit exactement comme vous l'avez écrit, et seul l'hôte finit par se plaindre.Bien calculer les deux sommes MSA est nécessaire et, selon le port dans lequel vous branchez, pas suffisant.
Cisco est l'exemple bien connu : la vérification d'identité ne se limite pas aux chaînes de caractères. Quelqu'un a établi il y a des années que la valeur portée par un module codé Cisco peut être reproduite avec rien de plus exotique que
xxd -r -p | md5sum, alimenté avec l'octet de code constructeur puis les octets du nom. Dans ces dumps, le code et le nom sont liés l'un à l'autre - Finisar se cache derrière 02, Methode derrière 0E. Faites que les deux ne concordent pas et un Catalyst 2960X recrache le module, commandes de déblocage ou pas.C'est généralement pour ça qu'un dump copié depuis un module fonctionnel cesse de fonctionner dès que quelqu'un y a collé une chaîne constructeur différente. Les sommes sont bonnes, l'identité n'est plus cohérente avec elle-même.
Petite correction sur le cadrage « corrigez les deux sommes et c'est réglé » : cela vaut pour les champs MSA, pas pour l'idée que chaque constructeur se fait d'une image valide.
HP est le contre-exemple classique. Modifiez le numéro de série dans une image J4858B, octets 68 à 83, et les octets 124 à 127 de la zone A0 changent aussi - une somme de contrôle constructeur située au-delà des octets MSA CC_BASE et CC_EXT. Le sujet a été longuement débattu et personne n'a jamais publié l'algorithme ; les gens ont confirmé que ces octets comptent et le fil s'est arrêté là. Même histoire rapportée autour du J4859C et du J9150A. Le matériel HP et Aruba plus récent est passé à un schéma de défi-réponse (HPIDv2), qu'on ne peut absolument pas falsifier dans une EEPROM.
Donc avant d'investir dans de l'outillage, déterminez ce que valide l'hôte cible : deux sommes additives pour un hôte simple, une identité cohérente en interne pour Catalyst, et sur certains modules HP un champ non documenté que vous n'allez pas reproduire.