IC-prog liefert 256 Byte SFP-Dump, aber die zweite Hälfte ist eine Kopie der ersten, Page A2 lässt sich nicht lesen (HP 2530-24G)
Betreue das Netz eines kleinen Betreibers und flashe regelmäßig billige Module auf HP um. Die Aufgabe ist die übliche: chinesischen 1.25G-WDM-Modulen das Image eines Markenmoduls einspielen, damit der Switch sie ohne Meckern annimmt. Spender ist ein J4859C, Zielgerät ein HP 2530-24G J9776A.
Was auf dem Tisch liegt:
- Switch HP 2530-24G J9776A
- Module OptiCin und Fiberstore, 1.25G WDM
- Mini-USB-Programmer NAG
- IC-prog unter Windows, darüber lese und schreibe ich
Der Dump kommt mit 256 Byte, aber die zweite Hälfte stimmt Byte für Byte mit der ersten überein:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedWas ich schon probiert habe:
- Modul umgesteckt, Kontakte im Sockel gereinigt, die Klemme gewechselt
- drei Module aus unterschiedlichen Chargen durchprobiert, gleiches Bild
- USB-Port, Kabel und Rechner gewechselt, nichts hat sich geändert
Ich brauche die zweite Seite mit DDM und den Servicebytes, und ich sehe sie einfach nicht. Ist das eine Grenze von IC-prog, eine krumme Programmer-Platine, oder verhalten sich die Module selbst so?
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
Hier gibt es zwei unabhängige Macken, und keine davon liegt an den Modulen.
Die erste ist IC-prog selbst. Es hat ein lineares Adressierungsmodell, kann keine Seiten umschalten und kommt an A2 grundsätzlich nicht heran. Was du in der zweiten Hälfte des Dumps siehst, ist dieselbe A0, ein zweites Mal gelesen. Einen Fehler zeigt es nicht an, weil aus seiner Sicht alles ehrlich zugeht.
Die zweite ist die Platine. Auf diesem Mini-USB-Programmer liegt VccR (Pin 15) fest auf +5 V, obwohl er laut SFF-8431 frei bleiben sollte, und Versorgung und Masse sind so verdrahtet, dass ein Teil der Module nicht in den normalen Modus geht. Daher auch
No Acknowledge received- nicht bei allen der Reihe nach, sondern bei denen, denen diese Verdrahtung nicht passt.Was normal funktioniert:
i2cdump -y 3 0x50undi2cdump -y 3 0x51, es gibt ein offenes Python-Skript, das beide Seiten liest und schreibt.Das Kriterium ist einfach: Sobald 0x51 anfängt zu antworten, ist alles Weitere normale Arbeit mit dem Modulspeicher und kein Kampf mit dem Werkzeug mehr.
Trenn Software und Hardware, sonst rätst du bis zum Abend. Nimm irgendein Linux und schau, ob das Modul auf der zweiten Adresse überhaupt antwortet:
Die Busnummer setz deine eigene ein. Wenn 0x50 sich lesen lässt und 0x51 schweigt, geht es nicht mehr darum, womit du den Dump anschaust, sondern ob überhaupt normale Spannung am Modul ankommt. Und sag, was derselbe Programmer beim nachweislich lebenden Spendermodul J4859C liefert: Öffnet sich auch bei dem die zweite Seite nicht, sind die billigen Module hier nicht das Problem, dann muss man in der Kombination aus Software und Platine graben.
Den Spender als Erstes durchprobiert: Der lebende J4859C liefert im selben Sockel und im selben IC-prog genau dasselbe Bild - 256 Byte, die zweite Hälfte wiederholt die erste. Also liegt es nicht an den billigen Modulen. Zusätzlich unter Linux über den Adapter geprüft:
Das Herstellertool gibt für dasselbe Modul
No Acknowledge receivedaus, IC-prog zeigt stillschweigend die Kopie der ersten Seite und tut so, als wäre alles in Ordnung. Zielmodule sind OptiCin, das Image ziehe ich genau von diesem J4859C.Zum Schreiben selbst noch was. Im 256-Byte-Dump zählen die ersten 128 Byte, danach kommt die Herstellerzone, die man meistens gar nicht anfassen muss. Für HP flashen wir Images von J4858C und J4859C, für WDM hat ein paar Mal ein gewöhnliches LX-Image gereicht: Der Switch hat das Modul angenommen und nicht auf die Wellenlänge geschaut.
Aber längst nicht alles lässt sich beschreiben. Bei 3Com 3CSFP91 und 3CSFP92, genauso wie bei gebrandeten Allied Telesis, ging das Schreiben gar nicht: Lesen funktioniert normal, Schreiben wird nicht übernommen, WP ist gelockt. Wenn also nach dem Programmerwechsel A2 sich lesen lässt, das Schreiben aber still ins Leere geht, dann nicht in der Software suchen.
Ein Vorbehalt zu „danach ist es normale Arbeit mit dem Speicher". Normal ist es nicht überall. Ein Teil der Module ist gar kein EEPROM: Im Medick SFP-10G-BX sitzt ein Mikrocontroller C8051F392, der A0/A2 emuliert und ein Passwort verlangen oder auf eine Challenge antworten kann. Von außen sieht das bis zum Moment des Schreibens wie normaler Speicher aus. Der übelste Fall, der mir untergekommen ist, war eine interaktive EEPROM bei HP/Aruba mit Schlüsseln, da ist ohne fertiges Tool nichts zu machen.
Und falls du den Adapter selbst baust, vertausch nicht die Beine: TX_Disable ist Pin 3, Mod_Abs Pin 6, VeeR Pin 9. Bei Bekannten stellte sich die Hälfte der „unlesbaren" Module als krumm gebauter Sockel heraus, nicht als Vendor-Schutz.
Was heute im Einsatz ist: SNR SFP Writer, die SFPTotal-Plus-Serie und Marke Eigenbau auf CH341-Basis - meistens einfach eine Platine mit Sockeln für SFP, XFP, GBIC und QSFP, manchmal im gedruckten Gehäuse. Universelle Software gibt es nicht, jeder Vendor hat sein eigenes Tool, Images zieht man aus Firmware-Datenbanken und einschlägigen Foren.
Zwei Punkte, die teurer sind als die Hardware. Erstens: Viele Module haben ein 4-Byte-Passwort, der Großteil davon ist längst veröffentlicht, aber daneben getippt und man hat einen Ziegelstein aus einem nicht gerade billigen Modul. Zweitens: Bevor du in den Speicher gehst, erst sicherstellen, dass das Modul überhaupt lebt. Temperatur, Spannung, Bias-Strom und TX/RX aus A0h/A2h,
show interfaces diagnostics opticsauf Junos oderdisplay interface transceiverauf Huawei, dann Klemmen, Kontakte und Linsen reinigen, dann Tausch gegen ein nachweislich funktionierendes Modul. Ein Teil der „toten" Module erwacht danach ohne jede Firmware wieder zum Leben, die Last prüft man erst danach über iperf3.Abschließender Bericht. Platine auf CH341-Basis gebaut, unter Linux hat 0x51 sofort geantwortet, die zweite Seite lässt sich komplett lesen, keine Duplikate der ersten 128 Byte mehr. Image von J4859C auf OptiCin geflasht, der HP 2530-24G J9776A hat das Modul stillschweigend angenommen, DDM zeigt plausible Werte, einen Tag unter Last ohne Fehler durchgehalten.
IC-prog runtergeworfen, damit ich nicht mehr in Versuchung komme. Das 3Com 3CSFP91, das noch danebenlag, lässt sich tatsächlich nicht beschreiben: liest sich, Schreiben wird nicht übernommen, die Sache mit WP passt also. Danke, Frage geklärt.