IC-prog renvoie 256 octets de dump SFP, mais la seconde moitié est une copie de la première, la page A2 ne se lit pas (HP 2530-24G)
Je gère le réseau d'un petit opérateur, je reflashe régulièrement des modules bon marché pour qu'ils passent pour du HP. Tâche habituelle : injecter dans des WDM 1,25G chinois l'image d'un module de marque, pour que le switch les accepte sans râler. Donneur - J4859C, matériel cible - HP 2530-24G J9776A.
Ce qu'il y a sur la table :
- switch HP 2530-24G J9776A
- modules OptiCin et Fiberstore, WDM 1,25G
- programmateur mini-USB NAG
- IC-prog sous Windows, je lis et j'écris via lui
Le dump fait 256 octets, mais la seconde moitié correspond exactement à la première, octet pour octet :
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedCe que j'ai déjà essayé :
- réinséré le module, nettoyé les contacts du socket, changé le loquet
- testé trois modules de lots différents, même résultat
- changé de port USB, de câble et de machine, rien n'a changé
J'ai besoin de la seconde page, où se trouvent le DDM et les octets de service, et je ne la vois tout simplement pas. Est-ce une limitation d'IC-prog, une carte de programmateur défectueuse, ou est-ce que les modules eux-mêmes se comportent ainsi ?
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 7
Il y a ici deux défauts indépendants, et aucun des deux n'est dans les modules.
Le premier - IC-prog lui-même. Il a un modèle d'adressage linéaire, il ne sait pas basculer entre pages et ne peut par principe pas atteindre A2. Ce que vous voyez dans la seconde moitié du dump, c'est la même A0, relue une seconde fois. Il ne montrera pas d'erreur, parce que de son point de vue tout est correct.
Le second - la carte. Sur ce programmateur mini-USB, VccR (broche 15) est câblé sur +5 V, alors que selon SFF-8431 il devrait rester libre, et en plus l'alimentation et la masse sont câblées de telle façon qu'une partie des modules ne passe pas en mode normal. D'où le
No Acknowledge received- pas sur tous indistinctement, mais sur ceux à qui ce câblage ne convient pas.Ce qui fonctionne normalement :
i2cdump -y 3 0x50eti2cdump -y 3 0x51, il existe un script Python libre qui lit et écrit les deux pages.Le critère est simple : dès que 0x51 se met à répondre, la suite est un travail normal avec la mémoire du module, plus une lutte avec l'outil.
Séparez le logiciel et le matériel, sinon vous allez deviner jusqu'au soir. Prenez n'importe quel Linux et regardez si le module répond ne serait-ce qu'à la seconde adresse :
Mettez votre propre numéro de bus. Si 0x50 se lit et que 0x51 reste muet - la question n'est plus de savoir avec quoi vous regardez le dump, mais si l'alimentation normale arrive au module. Et dites ce que renvoie, avec le même programmateur, un J4859C donneur assurément vivant : si chez lui aussi la seconde page ne s'ouvre pas, les modules bon marché n'y sont pour rien, il faut creuser du côté du couple logiciel plus carte.
J'ai testé le donneur en premier : un J4859C vivant, dans le même socket et le même IC-prog, donne exactement le même résultat - 256 octets, la seconde moitié répète la première. Donc ce n'est pas une affaire de modules bon marché. J'ai aussi vérifié sous Linux via l'adaptateur :
L'utilitaire d'origine sur ce même module renvoie
No Acknowledge received, alors qu'IC-prog affiche silencieusement une copie de la première page en faisant comme si tout allait bien. Les modules cibles sont des OptiCin, l'image je la prends justement sur ce J4859C.Sur l'écriture elle-même, j'ajoute ceci. Dans le dump de 256 octets, ce qui compte vraiment ce sont les 128 premiers octets, au-delà c'est la zone constructeur, qu'on peut généralement ne pas toucher du tout. Sous HP on injecte des images de J4858C et de J4859C, pour le WDM une simple image LX a suffi à quelques reprises : le switch acceptait le module sans regarder la longueur d'onde.
Mais tout n'est pas loin de s'écrire. Sur les 3Com 3CSFP91 et 3CSFP92, comme sur les Allied Telesis brandés, l'écriture n'est pas passée du tout : ça se lit normalement, mais l'écriture ne s'applique pas, WP verrouillé. Donc si après avoir changé de programmateur A2 se lit mais que l'écriture part silencieusement dans le vide, la cause n'est pas à chercher côté logiciel.
Je vais nuancer le « ensuite c'est un travail normal avec la mémoire ». Ce n'est pas normal partout. Une partie des modules ne sont pas du tout des EEPROM : dans les Medick SFP-10G-BX se trouve un microcontrôleur C8051F392 qui émule A0/A2 et peut exiger un mot de passe ou répondre à un challenge. De l'extérieur ça ressemble à une mémoire normale, exactement jusqu'au moment de l'écriture. Le cas le plus lourd que j'aie rencontré, c'est l'EEPROM interactive des HP/Aruba avec des clés, là sans utilitaire dédié il n'y a rien à faire.
Et si vous montez l'adaptateur vous-même, ne vous trompez pas de broches : TX_Disable - broche 3, Mod_Abs - broche 6, VeeR - broche 9. La moitié des modules « illisibles » chez des connaissances s'est révélée être un socket mal monté, pas une protection du vendor.
Parmi ce qu'on utilise actuellement : SNR SFP Writer, la série SFPTotal Plus et des montages maison à base de CH341 - en général c'est juste une carte avec des sockets pour SFP, XFP, GBIC et QSFP, parfois dans un boîtier imprimé. Il n'y a pas de logiciel universel, chaque vendor a son propre utilitaire, les images se récupèrent dans des bases de firmwares et sur les forums spécialisés.
Deux points qui coûtent plus cher que le matériel. Premier : beaucoup de modules ont un mot de passe sur 4 octets, la plupart sont publiés depuis longtemps, mais si vous vous trompez, vous obtenez une brique à partir d'un module qui n'était pas donné. Second : avant de toucher à la mémoire, assurez-vous que le module est bien vivant. Température, tension, courant de polarisation et TX/RX depuis A0h/A2h,
show interfaces diagnostics opticssous Junos oudisplay interface transceiversous Huawei, puis nettoyage des loquets, des contacts et des lentilles, puis remplacement par un module assurément fonctionnel. Une partie des modules « morts » revit après ça sans aucun flashage, et la charge on la vérifie ensuite via iperf3.Je fais le point sur le résultat. J'ai monté une carte à base de CH341, sous Linux 0x51 a répondu tout de suite, la seconde page se lit entièrement, aucun doublon des 128 premiers octets. J'ai injecté l'image du J4859C dans l'OptiCin, le HP 2530-24G J9776A a accepté le module sans broncher, le DDM affiche des valeurs cohérentes, une journée entière sous charge sans erreur.
J'ai désinstallé IC-prog pour ne plus être tenté. Le 3Com 3CSFP91 qui traînait à côté ne s'écrit effectivement pas : ça se lit, mais l'écriture ne s'applique pas, donc l'histoire du WP se confirme. Merci, la question est close.