Le programmateur renvoie WRITE FAIL sur un SFP+ qui se dump proprement : EEPROM morte ou quelque chose qui bloque les écritures ?
La plupart des mois, nous recodons un petit lot de modules pour les hôtes de nos clients, rien d'exotique : lire la page d'origine, écrire la chaîne constructeur voulue par l'hôte, mettre le module dans le commutateur et passer au suivant. Un module du lot actuel refuse toute écriture tout en se relisant parfaitement, et avant de le mettre au rebut, j'aimerais savoir s'il reste quelque chose à essayer.
Banc de test :
- programmateur USB de classe CH341 avec une carte d'interface SFP
- module SFP+, capable de diagnostics, se lit correctement à froid et après un cycle d'alimentation
- le même montage a écrit trois autres modules du même plateau une heure plus tôt
Ce que l'outil affiche au moment de lancer l'écriture :
WRITE FAILUne relecture immédiatement après me redonne la page d'origine octet pour octet, donc rien ne s'est inscrit du tout, même pas partiellement.
Ce que j'ai essayé :
- réinsertion du module et remplacement de la carte d'interface par une de rechange
- écriture d'un seul octet dans une zone qui m'importe peu au lieu de la page entière, même résultat
- vérification que la lecture est stable sur plusieurs cycles d'alimentation, donc le câblage n'est pas limite
Un module qui se lit proprement mais n'accepte jamais d'écriture est-il simplement usé, ou y a-t-il quelque chose dans le module lui-même qui peut refuser les écritures délibérément ?
Comments 5
Lecture propre, écritures refusées, page d'origine intacte ensuite. Ce n'est pas le comportement habituel d'une EEPROM usée. Des cellules mortes donnent une relecture erronée ou une page à moitié écrite, pas un refus net avec tout intact.
Et puisque même cet octet unique en dehors de la zone constructeur a été rejeté, ce n'est pas une région défectueuse sur la puce, c'est le module qui refuse les écritures en bloc. Deux choses valent la peine d'être vérifiées avant de conclure quoi que ce soit. D'abord, qui a réellement fabriqué le module : fiez-vous à la chaîne constructeur dans la page que vous avez déjà dumpée, pas à ce qui était marqué sur le plateau. Ensuite, si une écriture passe lorsqu'elle est lancée dès la mise sous tension, avant que quoi que ce soit d'autre sur le bus n'ait parlé au module. L'explication probable diffère selon ces réponses, et l'une d'elles n'est pas du tout un défaut.
Ça ressemble à une protection par mot de passe plutôt qu'à un dommage. Le SFF-8472 permet à un module capable de diagnostics d'exiger un mot de passe de 4 octets avant d'accepter toute écriture. N'envoyez rien, ou envoyez le mauvais, et le module répond à l'écriture par une erreur tandis que les lectures restent grandes ouvertes, ce qui correspond exactement à votre WRITE FAIL avec la page qui revient inchangée. C'est une fonctionnalité du module, pas le symptôme d'un module mourant.
Ce que cela implique pour votre banc : un programmateur qui connaît cette fonctionnalité vous permet de saisir un mot de passe constructeur ou hôte, et les meilleurs feront une attaque par force brute sur un mot de passe inconnu et recalculeront les sommes de contrôle pour vous après l'écriture. Un montage de classe CH341 n'a aucune automatisation des sommes de contrôle, donc même une fois le mot de passe passé, vous devez corriger vous-même les sommes de contrôle, sinon vous vous retrouvez avec un module dont la page vous semble correcte mais que l'hôte refuse quand même.
Réserve habituelle : j'ai rencontré ça sur une poignée de modules et la piste du mot de passe a fonctionné là, donc essayez-la sur votre propre module avant d'écarter quoi que ce soit.
Pour compléter : chez certains fabricants, les mots de passe ne sont pas vraiment secrets. Il circule des listes partagées de mots de passe de transceivers Ubiquiti avec des entrées comme 0x00001011 et de simples chaînes telles que SFPX et QSFP, donc si le module vient de cet écosystème, ça ne coûte que cinq minutes d'essayer les valeurs connues avant de s'approcher de la force brute.
Et si vous voulez un outil qui connaît déjà tout le flux plutôt que de lutter avec un programmateur générique, l'UACC-SFP-WIZARD est l'option économique vers laquelle les gens se tournent. Ce n'est pas un instrument de laboratoire, mais il gère correctement le côté module.
En lien avec ça, à propos du recodage de modules pour des hôtes Huawei S5731 et S6730 et un vieux HP 6120XG. Quand la cage ou la carte d'interface est le maillon faible plutôt que le module, on soude directement sur les broches 4 et 7 du module, qui sont les lignes I2C SDA et SCL, et on pilote l'EEPROM en écartant complètement la cage. C'est moche, et on ne le fait que sur des pièces qu'on est prêt à perdre, mais ça élimine toute une catégorie de problèmes de contact.
Modules qui sont passés par là ici : Finisar FTLX8571D3BCV et FTLX8574D3BCV, modules Intel SFP+ LR et SR, SNR-SFP+W73-3 et SNR-SFP+W37-3, plus un HP J9150A.
Dans votre cas, la lecture est déjà parfaitement stable sur plusieurs cycles d'alimentation, donc le contact n'est pas votre problème. Explorez d'abord la piste du mot de passe.
Le mot de passe est probablement la bonne réponse, mais ne vous arrêtez pas à « tapez le mot de passe et c'est réglé », car deux choses piègent les gens juste après.
D'abord, sur certains modules, la saisie doit être refaite après que le module a été mis hors tension, donc un script qui écrit plusieurs pages en séquence doit être prêt à la ressaisir plutôt que de supposer qu'un seul déverrouillage couvre toute la session.
Ensuite, les sommes de contrôle. Avec un programmateur de classe CH341, vous les recalculez à la main. Laissez-les obsolètes et le module se relira quand même correctement, votre outil annoncera un succès, et l'hôte refusera quand même discrètement le module, moment où tout le monde recommence à accuser le matériel. Relisez la page et vérifiez les sommes avant que ce module ne parte dans le commutateur d'un client.