Programmer meldet WRITE FAIL bei einem SFP+, das sich sauber auslesen lässt: totes EEPROM oder blockiert etwas die Schreibzugriffe
Wir codieren die meisten Monate eine kleine Charge Module für Kundenhosts um, nichts Exotisches: die Originalseite lesen, den Vendor-String schreiben, den der Host will, das Modul in den Switch stecken und weitermachen. Ein Modul aus der aktuellen Charge verweigert jeden Schreibvorgang, während es sich perfekt zurückliest, und bevor ich es wegwerfe, würde ich gern wissen, ob noch etwas zu versuchen bleibt.
Aufbau:
- USB-Programmer der CH341-Klasse mit SFP-Breakout-Board
- SFP+-Modul, diagnosefähig, liest sich kalt und nach einem Power Cycle einwandfrei aus
- derselbe Aufbau hat eine Stunde zuvor drei andere Module aus demselben Tray beschrieben
Was das Tool im Moment des Schreibbefehls ausgibt:
WRITE FAILDirektes erneutes Auslesen danach liefert mir die Originalseite Byte für Byte zurück, es ist also gar nichts angekommen, nicht mal teilweise.
Was ich versucht habe:
- Modul neu gesteckt und das Breakout-Board gegen ein Ersatzteil getauscht
- statt der ganzen Seite nur ein einzelnes Byte in einem Bereich geschrieben, der mir egal ist, gleiches Ergebnis
- bestätigt, dass das Lesen über mehrere Power Cycles stabil bleibt, die Verkabelung also nicht grenzwertig ist
Ist ein Modul, das sich sauber ausliest, aber nie einen Schreibvorgang akzeptiert, einfach verschlissen, oder gibt es im Modul selbst etwas, das Schreibzugriffe absichtlich verweigern kann?
Comments 5
Liest sich sauber aus, Schreiben wird verweigert, Originalseite danach intakt. So verhält sich ein verschlissenes EEPROM normalerweise nicht. Tote Zellen liefern dir ein schlechtes Rücklesen oder eine Seite, die nur zur Hälfte geschrieben wurde, keine saubere Verweigerung mit allem unangetastet.
Und da sogar dieses einzelne Byte außerhalb des Vendor-Bereichs abgeprallt ist, ist das kein schlechter Bereich auf dem Chip, das Teil weist Schreibzugriffe pauschal ab. Zwei Dinge lohnt es sich zu klären, bevor du irgendetwas entscheidest. Erstens, wer das Modul tatsächlich gebaut hat: Geh nach dem Vendor-String in der Seite, die du schon gedumpt hast, nicht danach, wie das Tray beschriftet war. Zweitens, ob ein Schreibvorgang ankommt, wenn du ihn genau in dem Moment auslöst, in dem die Spannung kommt, bevor sonst irgendetwas auf dem Bus mit dem Modul gesprochen hat. Die wahrscheinliche Erklärung unterscheidet sich je nach diesen Antworten, und eine davon ist gar kein Defekt.
Das liest sich eher nach Passwortschutz als nach einem Schaden. SFF-8472 erlaubt einem diagnosefähigen Modul, ein 4-Byte-Passwort zu verlangen, bevor es irgendeinen Schreibvorgang akzeptiert. Schickst du nichts oder das falsche, beantwortet das Modul den Schreibvorgang mit einem Fehler, während Lesen weiterhin offensteht, genau dein WRITE FAIL mit unveränderter Seite danach. Das ist ein Feature des Teils, kein Symptom eines sterbenden.
Was das für deinen Aufbau bedeutet: Ein Programmer, der das kennt, lässt dich ein Hersteller- oder Host-Passwort eingeben, und die besseren bruteforcen ein unbekanntes und berechnen dir nach dem Schreiben die Prüfsummen neu. Ein Aufbau der CH341-Klasse hat überhaupt keine Prüfsummen-Automatik, selbst nachdem du am Passwort vorbei bist, musst du die Prüfsummen also selbst korrigieren, sonst landest du bei einem Modul, dessen Seite für dich richtig aussieht und das der Host trotzdem ablehnt.
Übliche Einschränkung: Ich bin darauf bei einer Handvoll Module gestoßen, und der Passwort-Weg hat dort funktioniert, also probier es an deinem eigenen Teil, bevor du irgendetwas abschreibst.
Ergänzend dazu: Bei manchen Herstellern sind die Passwörter nicht wirklich geheim. Es kursieren geteilte Sammlungen von Ubiquiti-Transceiver-Passwörtern mit Einträgen wie 0x00001011 und einfachen Strings wie SFPX und QSFP, kommt das Modul also aus diesem Ökosystem, kostet es dich fünf Minuten, die bekannten zu probieren, bevor du überhaupt in Richtung Bruteforce gehst.
Und falls du ein Tool willst, das den ganzen Ablauf schon kennt, statt dich mit einem generischen Programmer herumzuschlagen: Der UACC-SFP-WIZARD ist die günstige Option, zu der die Leute greifen. Kein Laborinstrument, aber er handhabt die Modulseite ordentlich.
Verwandt, aus dem Umcodieren von Modulen für Huawei-S5731- und S6730-Hosts und einen alten HP 6120XG. Wenn der Käfig oder das Breakout das schwache Glied ist und nicht das Modul, löten Leute direkt an Pin 4 und 7 des Moduls, das sind die I2C-Leitungen SDA und SCL, und steuern das EEPROM an, wobei der Käfig komplett aus dem Spiel ist. Hässlich, und man macht das nur bei Teilen, die man zu verlieren bereit ist, aber es entfernt eine ganze Klasse von Kontaktproblemen.
Teile, die das hier durchlaufen haben: Finisar FTLX8571D3BCV und FTLX8574D3BCV, Intel-SFP+-LR- und -SR-Module, SNR-SFP+W73-3 und SNR-SFP+W37-3, dazu ein HP J9150A.
In deinem Fall ist das Lesen über Power Cycles hinweg schon felsenfest, Kontakt ist also nicht dein Problem. Jag zuerst der Passwort-Spur nach.
Passwort ist die wahrscheinliche Antwort, aber lass es nicht bei "Passwort eingeben und fertig" bewenden, denn direkt danach beißen zwei Dinge zu.
Erstens, bei manchen Teilen wird die Eingabe erneut verlangt, nachdem das Modul spannungslos war, ein Skript, das mehrere Seiten nacheinander schreibt, muss also darauf vorbereitet sein, es erneut einzugeben, statt anzunehmen, ein Unlock decke die ganze Sitzung ab.
Zweitens, die Prüfsummen. Mit einem Programmer der CH341-Klasse berechnest du sie von Hand neu. Lässt du sie veraltet, liest sich das Modul trotzdem sauber aus, dein Tool meldet Erfolg, und der Host verweigert das Modul trotzdem still und leise, und dann geben wieder alle der Hardware die Schuld. Lies die Seite zurück und verifiziere die Summen, bevor das Modul in einen Kundenswitch wandert.