Recodage de l’EEPROM : mots de passe et mécanique

L’enseignement clé de plusieurs années de discussions techniques : la compatibilité d’un transceiver n’est pas une question de firmware — ce sont des chaînes d’identification dans l’EEPROM, lues par I²C. Un commutateur rejette un module simplement parce qu’il ne reconnaît pas la chaîne fournisseur. Ce seul fait explique la pratique courante consistant à « tout coder en Cisco — ça marche presque partout » ainsi que tout le marché des outils de codage.

Où se trouvent les mots de passe

Écrire dans les zones protégées de la mémoire du module exige un mot de passe de 4 octets saisi à une adresse fixe avant l’écriture :

Mots de passe couramment cités

Certains modules QSFP-DD de certains fournisseurs sont livrés avec leurs propres valeurs par défaut fixes, et quelques modules à microprocesseur utilisent un mot de passe variable qui change — un piège pour qui tente une attaque par force brute.

Pourquoi la force brute n’est pas la solution

Un mot de passe de niveau fabricant protégeant toute la carte mémoire demande de l’ordre de 100+ jours pour être cassé par force brute ; même un mot de passe ASCII de niveau hôte prend jusqu’à environ trois jours. La voie pratique est une base de données de codes et de mots de passe connus capturés sur des modules d’origine — c’est là que réside la vraie valeur d’un outil de codage, pas dans le matériel I²C (qui est simple).

Pièges des programmateurs bricolés

• Les programmateurs CH341A bon marché ne calculent pas la somme de contrôle SFP. Écrire une image sans CC_BASE/CC_EXT valides produit un module que le commutateur rejettera. Il vous faut un outil qui recalcule les sommes de contrôle automatiquement.
• Certains commutateurs n’écrivent qu’à l’adresse 0x50, si bien que le mot de passe à 0x51 ne peut pas être atteint depuis le commutateur lui-même — une vraie carte programmateur est nécessaire.
• La broche de protection en écriture de l’EEPROM — certaines usines relient WP à Vcc, si bien que le module est verrouillé contre l’écriture sur le terrain.

Cas rencontrés sur le terrain

• Des modules codés pour un fournisseur ne voulaient pas s’autonégocier sur un commutateur d’un autre ; recodés avec la chaîne fournisseur propre au commutateur, ils se sont établis immédiatement.
• Certains fournisseurs d’optiques livrent volontairement des modules non codés, en s’attendant à ce que l’acheteur les code pour la plateforme cible.
• Les modules DWDM sont accordés en longueur d’onde via la même interface de gestion que celle utilisée pour le codage.

Le faire dans CodingBox

1. Lisez le module ; il est enregistré automatiquement dans la code database et une sauvegarde est prise avant toute écriture.
2. Réglez l’adresse de table, l’adresse du mot de passe et la valeur du mot de passe dans Mémoire protégée en écriture et mots de passe — les mots de passe connus de la base sont appliqués automatiquement.
3. Modifiez le fournisseur, la référence et les autres champs d’identité dans l’EEPROM editor. CC_BASE et CC_EXT sont recalculés pour vous.
4. Écrivez les pages sélectionnées, puis relisez pour vérifier. Contrôlez le module sur le commutateur avec les commandes de Vérifier les optiques.

Ne codez des modules que pour l’interopérabilité à laquelle vous avez droit, et respectez les politiques de votre organisation et des fournisseurs.

Les règles d’un recodage propre — formats des champs, quels bits positionner et quelles sommes corriger — sont dans Champs fabricant, Codes de conformité et Sommes de contrôle.

Ce que fait l’usine à la même étape, et quelles zones contiennent un étalonnage qu’une écriture imprudente peut détruire : Fabrication et tests, Contrôleur et firmware.

Quel octet contient quoi avant l’édition : SFF-8472 A0h, SFF-8636 page haute, CMIS pages hautes, XFP.

Références cibles et leur grammaire par fournisseur : Numérotation des pièces ; ce que chaque famille de plateforme vérifie après l’écriture : Comment chaque OS réseau valide un module.