Le programmateur lit le SFP+ FTLX8571D3BCV-IT mais répond No Acknowledge à l'écriture
Je gère un petit fonds d'échange de modules : les sites sont dispersés dans la ville, et sous presque chaque switch d'autrui il faut recoder un SFP. Avec les modules gigabit le schéma est rodé depuis longtemps, mais là je bloque sur du 10G.
Ce qu'il y a sur la table :
- programmateur avec cage pour SFP/SFP+, alimentation 3,3 V
- Finisar FTLX8571D3BCV-IT et FTLX1471D3BCV-IT, les deux se lisent
- Cisco GLC-LH-SM de vieux stocks
- HP J4858B et J4859C
La lecture se fait de façon stable et reproductible, les deux banques en entier. L'écriture ne passe dans aucun cas :
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeCe qui a déjà été vérifié :
- les mêmes opérations sur des SFP gigabit classiques avec le même programmateur passent, donc l'électronique et l'alimentation sont vivantes ;
- pris un deuxième exemplaire de FTLX8571D3BCV-IT, comportement identique octet pour octet ;
- sur le GLC-LH-SM le No Acknowledge arrive tout de suite, avant même de tenter de toucher aux champs vendeur.
Donc ce n'est pas l'exemplaire en cause. Est-ce une protection matérielle d'écriture dans le module lui-même, ou est-ce que dans le SFP+ la mémoire n'est plus une EEPROM nue et qu'une écriture I2C classique ne peut simplement pas y accéder ? Et question à part sur les HP J4858B/J4859C : quelqu'un les écrit-il avec un programmateur classique, ou c'est une impasse connue d'avance ?
Comments 6
Il y a deux mécanismes différents qui se mélangent ici, et ils se traitent différemment.
Le premier - une EEPROM classique avec protection matérielle d'écriture. La puce mémoire a une broche write protect, et tant qu'elle est tirée, la lecture passe mais l'écriture échoue. La méthode conseillée par des gens qui ont creusé ça sérieusement, c'est de mettre cette broche à la masse pendant le flashage. Sur une partie des modules gigabit, ça suffit.
Le second - ce sur quoi tu es tombé sur le 10G. Dans le SFP+, les données sont souvent non pas dans une EEPROM séparée, mais derrière le microcontrôleur du module : c'est lui qui rend A0 et A2 en lecture et n'accepte l'écriture que via sa propre séquence de commandes. Un programmateur standard ne connaît pas cette séquence et reçoit un No Acknowledge à toute tentative, peu importe le champ visé. Il n'y a rien à mettre à la masse là-dedans.
Ce qui aide réellement à contourner la cage : souder des fils directement sur les broches 4 et 7 du module, c'est-à-dire les lignes I2C, en contournant le connecteur du programmateur. D'après les retours, ça permet d'écrire sur une partie des modules qui restaient silencieux dans la cage. La méthode est brutale, il faut la main sûre, et le module vit après ça à tes risques.
Le HP, c'est une autre histoire. Les programmateurs standards ne les acceptent pas, il faut un traitement propre, et sur les J4858B/J4859C avec une électronique classique je ne m'attendrais pas à un succès. Si le but est simplement d'obtenir un module fonctionnel dans un switch d'autrui, il est moins cher de ne pas se battre avec le HP et de prendre un module à mémoire honnête et d'y copier l'image vendeur en entier : sur les 256 octets du dump, les 128 premiers comptent, le reste est de la réserve constructeur.
Aucun vendeur, bien sûr, ne supporte ce genre de recodage : avec un module reflashé, il n'y a rien à présenter au support.
Précise deux ou trois choses, sinon ça reste de la devinette. Le No Acknowledge arrive-t-il sur l'adresse du périphérique elle-même, ou déjà après le premier octet de données ? C'est en général visible dans le log du programmateur. Et c'est quoi ton programmateur - un appareil du commerce ou une bidouille avec sa propre électronique ? Ça détermine ce qu'on peut attendre du 3,3 V sur la cage.
Autre chose intéressante, le comportement à la mise sous tension : l'échec est-il identique juste après l'installation du module et après qu'il soit resté sous tension quelques minutes ? Et les quatre types se comportent-ils pareil, ou est-ce que Finisar et HP diffèrent : le HP a généralement ses propres raisons d'échec, mieux vaut les séparer du reste tout de suite.
Je rends compte du résultat. Soudé sur les lignes I2C directement aux broches 4 et 7, en contournant la cage. Les Finisar sont passés : le FTLX8571D3BCV-IT s'est écrit et a été confirmé par relecture, le FTLX1471D3BCV-IT aussi. Le GLC-LH-SM a arrêté de renvoyer No Acknowledge et s'écrit normalement.
Le HP n'a pas cédé. Le J4858B accepte formellement l'écriture, mais après la modification le module est rejeté par le switch, le J4859C se comporte pareil. Donc pour moi la question est à moitié close : Finisar et Cisco, j'écris maintenant, le HP, je le mets de côté pour des jours meilleurs.
Avec le HP le piège est plus profond qu'une simple protection d'écriture, donc ton résultat était prévisible. Sur le J4858B, en modifiant les octets 68-83, c'est-à-dire le numéro de série, la somme de contrôle dans les octets 124-127 change, et le module est ensuite rejeté. Ce ne sont pas les CC_BASE et CC_EXT du MSA, celles-là ne posent pas de problème à calculer, mais une somme vendeur à part dans les quatre derniers octets d'A0. L'algorithme n'a jamais été percé publiquement, malgré tout ce qu'on a essayé.
Le J9150A vient de la même histoire. Et dans les modules HP et Aruba plus récents, on est carrément passés d'une somme statique à un schéma requête-réponse, HPIDv2, et là un programmateur est inutile par principe. Donc « ça s'écrit mais ce n'est pas accepté » est exactement ce à quoi il fallait s'attendre.
Vu que tu as un parc et pas un seul module, je dis un mot de l'outil. Pour le recodage pour Huawei S5731 et S6730 et pour HP 6120XG, j'ai adapté l'UACC-SFP-WIZARD d'Ubiquiti - comme programmateur bon marché il est plutôt vivant. Seulement, sur les modules Ubiquiti eux-mêmes circulent des listes de mots de passe, des entrées du genre 0x00001011, SFPX, QSFP, et sans elles une partie des modules ne s'ouvre pas à l'écriture. Comme images j'utilise couramment FTLX8571D3BCV et FTLX8574D3BCV, plus rarement SNR-SFP+W73-3 et W37-3.
Je corrige la généralisation ci-dessus, pour que personne ne se jette sur le fer à souder trop vite : ce n'est pas dans chaque SFP+ que la mémoire est cachée derrière un microcontrôleur. Chez moi, le FTLX8574D3BCV et une paire de SNR-SFP+W73-3 se sont écrits avec un programmateur classique dans la cage, sans aucune soudure. Donc il vaut mieux d'abord vérifier l'exemplaire concret, et ensuite seulement passer au contournement.
Mettre à la masse la broche write protect, d'ailleurs, n'est pas non plus une recette universelle : sur un module à microcontrôleur, ça ne donne rien, l'échec ne vient pas de la mémoire mais du firmware du contrôleur. Cette opération n'a de sens que là où il y a une vraie EEPROM séparée, et il faut la faire module hors tension, sinon on récupère facilement une brique à la place d'un module.