Programmiergerät liest SFP+ FTLX8571D3BCV-IT aus, antwortet beim Schreiben aber mit No Acknowledge
Ich halte einen kleinen Pool an Tauschmodulen: Die Knoten sind über die Stadt verteilt, und für fast jeden fremden Switch muss ein SFP umkodiert werden. Bei den Gigabit-Modulen ist das Verfahren längst eingespielt, aber beim Zehner bin ich hängengeblieben.
Was auf dem Tisch liegt:
- Programmiergerät mit Cage für SFP/SFP+, Versorgung 3,3 V
- Finisar FTLX8571D3BCV-IT und FTLX1471D3BCV-IT, beide lesen sich aus
- Cisco GLC-LH-SM aus alten Beständen
- HP J4858B und J4859C
Das Lesen klappt stabil und wiederholbar, beide Bänke komplett. Das Schreiben geht in keiner Variante:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeWas schon geprüft ist:
- dieselben Operationen an gewöhnlichen Gigabit-SFPs laufen mit demselben Programmiergerät durch, die Beschaltung und die Versorgung leben also;
- ein zweites Exemplar des FTLX8571D3BCV-IT genommen, Verhalten byteweise identisch;
- beim GLC-LH-SM kommt No Acknowledge sofort, noch bevor überhaupt versucht wird, die Vendor-Felder anzufassen.
Es liegt also nicht am konkreten Exemplar. Ist das ein Hardware-Schreibschutz im Modul selbst, oder steckt hinter SFP+ längst keine nackte EEPROM mehr, sodass ein normaler I2C-Schreibzugriff da gar nicht erst hinkommt? Und getrennt davon interessiert mich HP J4858B/J4859C: Schreibt die jemand mit einem gewöhnlichen Programmiergerät, oder ist das von vornherein aussichtslos?
Comments 6
Hier vermischen sich zwei verschiedene Mechanismen, und behoben werden sie unterschiedlich.
Der erste: eine gewöhnliche EEPROM mit Hardware-Schreibschutz. Der Speicherbaustein hat einen Write-Protect-Pin, und solange der gezogen ist, klappt das Lesen, aber das Schreiben bricht ab. Der Weg, den Leute empfehlen, die sich damit intensiv beschäftigt haben: diesen Pin für die Dauer des Flashens auf Masse legen. Bei einem Teil der Gigabit-Module reicht das.
Der zweite: das, worauf du beim Zehner gestoßen bist. Bei SFP+ liegen die Daten oft nicht in einer separaten EEPROM, sondern hinter dem Mikrocontroller des Moduls: Der gibt A0 und A2 selbst zum Lesen heraus und nimmt Schreibzugriffe nur über seine eigene Kommandosequenz an. Ein Standard-Programmiergerät kennt diese Sequenz nicht und bekommt bei jedem Versuch No Acknowledge, egal auf welches Feld gezielt wird. Da gibt es nichts zu erden.
Was wirklich hilft, um die Cage zu umgehen: mit Drahtbrücken direkt an die Pins 4 und 7 des Moduls löten, also auf die I2C-Leitung, am Programmierer-Stecker vorbei. Berichten zufolge lässt sich danach ein Teil der Module beschreiben, die in der Cage stumm blieben. Die Methode ist grob, es braucht ruhige Hände, und das Modul läuft danach auf eigenes Risiko weiter.
HP ist ein eigenes Kapitel. Standard-Programmiergeräte kommen da nicht ran, das braucht eine eigene Behandlung, und bei J4858B/J4859C mit gewöhnlicher Beschaltung würde ich keinen Erfolg erwarten. Wenn es nur darum geht, ein funktionierendes Modul in einem fremden Switch zu bekommen, ist es billiger, HP nicht zu quälen, sondern ein Modul mit ehrlichem Speicher zu nehmen und dort das komplette Vendor-Image reinzuschreiben: Von den 256 Byte des Dumps zählen die ersten 128, der Rest ist Reserve des Herstellers.
Kein Vendor unterstützt so ein Umkodieren natürlich: Mit einem umgeflashten Modul gibt es beim Support nichts zu holen.
Klär ein paar Dinge, sonst wird das reine Raterei. Kommt No Acknowledge schon bei der Geräteadresse selbst oder erst nach dem ersten Datenbyte? Im Log des Programmiergeräts sieht man das normalerweise. Und was für ein Programmiergerät ist das: ein fertiges Gerät oder ein Eigenbau mit eigener Beschaltung? Davon hängt ab, was von den 3,3 V an der Cage überhaupt zu erwarten ist.
Noch interessant ist das Verhalten beim Anlegen der Spannung: Ist der Fehler gleich direkt nach dem Einsetzen des Moduls und auch, nachdem es ein paar Minuten unter Spannung stand? Und verhalten sich alle vier Typen gleich, oder unterscheiden sich Finisar und HP: Bei HP gibt es meist eigene Fehlerursachen, die sollte man gleich von den anderen trennen.
Kurzer Statusbericht. Direkt auf der I2C-Leitung an die Pins 4 und 7 gelötet, an der Cage vorbei. Finisar ging: FTLX8571D3BCV-IT hat geschrieben und wurde durch Rücklesen bestätigt, FTLX1471D3BCV-IT ebenso. GLC-LH-SM gibt kein No Acknowledge mehr und schreibt sich normal.
HP hat sich nicht ergeben. J4858B nimmt das Schreiben formal an, aber nach der Änderung weist der Switch das Modul zurück, J4859C verhält sich genauso. Für mich ist die Frage also zur Hälfte erledigt: Finisar und Cisco schreibe ich jetzt, HP habe ich erstmal beiseitegelegt.
Bei HP liegt die Falle tiefer als nur im Schreibschutz, dein Ergebnis ist also zu erwarten. Beim J4858B ändert sich beim Bearbeiten der Bytes 68-83, also der Seriennummer, die Prüfsumme in den Bytes 124-127, und das Modul wird danach zurückgewiesen. Das sind nicht die MSA-Prüfsummen CC_BASE und CC_EXT, die zu berechnen kein Problem ist, sondern eine eigene Vendor-Prüfsumme in den letzten vier Bytes von A0. Den Algorithmus hat trotz allem Herumstochern öffentlich niemand aufgedröselt.
J9150A gehört zur selben Geschichte. Und in neueren HP- und Aruba-Modulen ist man von der statischen Prüfsumme ohnehin auf ein Frage-Antwort-Schema umgestiegen, HPIDv2, und da ist ein Programmiergerät prinzipiell nutzlos. Also: „schreibt sich, wird aber nicht angenommen" ist genau das, was dabei herauskommen musste.
Weil du einen ganzen Park hast und nicht nur ein Modul, kurz zum Werkzeug. Für die Umkodierung für Huawei S5731 und S6730 sowie für HP 6120XG habe ich den UACC-SFP-WIZARD von Ubiquiti eingesetzt: als billiges Programmiergerät ist er durchaus brauchbar. Nur kursieren zu den Ubiquiti-Modulen selbst Passwortlisten, Einträge der Form 0x00001011, SFPX, QSFP, und ohne die öffnet sich ein Teil der Module zum Schreiben nicht. An Images habe ich FTLX8571D3BCV und FTLX8574D3BCV im Einsatz, seltener SNR-SFP+W73-3 und W37-3.
Kleine Korrektur zur Verallgemeinerung oben, damit niemand vorschnell zum Lötkolben greift: Nicht bei jedem SFP+ steckt der Speicher hinter einem Mikrocontroller. Bei mir haben sich FTLX8574D3BCV und ein paar SNR-SFP+W73-3 mit einem gewöhnlichen Programmiergerät in der Cage beschreiben lassen, ganz ohne Löten. Also erst das konkrete Exemplar prüfen und erst danach zur Umgehung greifen.
Das Erden des Write-Protect-Pins ist übrigens auch kein Universalrezept: Bei einem Modul mit Mikrocontroller bringt das nichts, der Fehler kommt dort nicht vom Speicher, sondern von der Firmware des Controllers. Sinn hat diese Operation nur dort, wo eine ehrliche separate EEPROM sitzt, und sie muss am stromlosen Modul gemacht werden, sonst wird aus dem Modul schnell ein Ziegelstein.