SFP-EEPROM über den I2C-Bus des Raspberry Pi lesen und neu schreiben, statt einen Programmer zu kaufen
Ich habe zu Hause ein Regal voller ausgebauter SFPs und würde gerne ihr EEPROM lesen, ein Modul mit zerschossener Prüfsumme reparieren und gelegentlich eines für einen Switch umcodieren können, der bei Herstellerstrings pingelig ist. Einen kommerziellen Programmer für eine Handvoll Module im Jahr zu kaufen ergibt hier keinen Sinn, also versuche ich herauszufinden, wie weit ein selbstgebauter Aufbau tatsächlich kommt.
Was auf der Werkbank steht:
- Raspberry Pi, dessen I2C-Bus ich selbst auf einen SFP-Käfig herausgeführt habe
- eine CH341A-USB-Programmer-Platine, übrig von einem BIOS-Job
- ein gemischter Haufen 1G- und 10G-SFP/SFP+-Module, dazu zwei QSFP+-Module, die ich mir auch gerne ansehen würde
Lesezugriffe funktionieren zumindest in dem Sinn, dass auf dem Bus etwas antwortet:
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
$ i2cdump -y 1 0x50Was ich bisher gemacht habe:
- A0h von Hand gedumpt und die Bytes gegen die SFF-8472-Feld-Offsets verglichen, was langsam ist und sich leicht vertun lässt
- ein paar Bytes mit dem CH341A geschrieben: Sie landen, aber nichts berechnet mir die Prüfsummen neu, also kommt das Modul als Müll zurück, bis ich sie selbst patche
- die QSFP+-Module unangetastet gelassen, weil der von mir gebaute Käfig nur SFP aufnimmt
Wie sieht das offene Tooling dafür also tatsächlich aus: Gibt es etwas, das das Speicherlayout kennt, die Prüfsummenbytes nach einem Schreibvorgang verifiziert und auch einen QSFP+-Slot ansteuern kann? Und wo hört ein selbstgebauter Aufbau auf, auszureichen?
Comments 4
Für reine SFP/SFP+-Arbeit reicht der Pi. Das Modul ist einfach zwei I2C-Geräte, genau das zeigt deine i2cdetect-Ausgabe bei 0x50 und 0x51, und darüber hinaus passiert nichts Magisches. Was einem das Byte-Zählen erspart, ist sfppi: Es steuert den I2C-Bus des Pi an, decodiert die Felder, prüft CC_BASE und CC_EXT und bietet an, sie nach einem Schreibvorgang zu reparieren. Genau das ist der Schritt, den der CH341A einem nicht abnimmt. Der CH341A ist nicht nutzlos, er liest und schreibt einwandfrei, er weiß nur nicht, was die Bytes bedeuten, also bleibt jede Prüfsumme dein Problem.
Für QSFP+ hilft dein gelöteter Käfig nicht weiter. Das Design, auf das die Community verweist, ist Hubble, ein offener Programmer mit einem QSFP-Slot neben dem SFP-Slot, das ist also die Richtung, wenn du diese beiden Module anfassen willst. Es gibt außerdem einen abgespeckten Reveltronics-Aufbau, der zum Brute-Forcen von Schreibpasswörtern bei Modulen benutzt wird, die Schreibzugriffe rundweg verweigern. Den habe ich selbst nie gebraucht, also als Hinweis behandeln und an Hardware prüfen, deren Verlust man verschmerzen kann.
Das deckt sich mit dem, was ich hier sehe. Die zweite Seite ist ebenfalls da, beide Hälften des Speichers lassen sich also lesen:
Ich werde die Käfigverkabelung sauber neu machen und dann den Prüfsummen-Weg an einem Modul ausprobieren, das mir egal ist, bevor ich etwas anfasse, das ich behalten will. QSFP+ bleibt erstmal geparkt, einen zweiten Käfig für zwei Module im Jahr zu bauen ist schwer zu rechtfertigen, also bleiben die nur lesbar, bis ich entscheide, ob Hubble den Aufwand wert ist.
Noch etwas vom anderen Ende der Preisspanne, weil nicht jeder selbst baut: Die Tools, die man im Alltag sieht, sind der SNR SFP Writer, die SFPTotal-Plus-Serie und diverse Einzelbauten rund um CH341-Boards, also denselben Chip, den du schon auf der Werkbank hast.
Was es zu wissen lohnt, bevor man tiefer einsteigt: Nicht jedes Modul ist ein simples EEPROM. Manche tragen einen eigenen Mikrocontroller, der den A0/A2-Speicher emuliert, statt einen echten Chip offenzulegen, ein Medick SFP-10G-BX mit einem C8051F392 drin ist das Beispiel, das immer wieder auftaucht. Die können Schreibpasswörter oder Vendor-Challenges implementieren, und egal wie sehr man am Bus herumstochert, wird daraus kein dummes EEPROM. Der übelste Fall, den Leute anführen, ist das interaktive HP/Aruba-EEPROM mit Keys.
Ein praktischer Hinweis für den eigenen Käfig: Das Pinout richtig hinbekommen, sonst jagt man Gespenster. TX_Disable ist Pin 3, Mod_Abs ist Pin 6, VeeR ist Pin 9. Mod_Abs entscheidet insbesondere, ob überhaupt irgendetwas glaubt, dass ein Modul steckt.
Und die Risikoseite davon, weil die selten erwähnt wird, bis jemand ein totes Modul hat. Viele Module wollen ein 4-Byte-Passwort, bevor sie einen Schreibvorgang akzeptieren. Die meisten dieser Passwörter kursieren öffentlich, und es gibt kein universelles Utility, also landet man bei einem Haufen herstellerspezifischer Tools und Images aus Firmware-Datenbanken oder vom Hersteller. Etwas davon falsch gemacht, und man hat ein Modul gebrickt, das mehr gekostet hat als der Programmer.
Bevor man also überhaupt das EEPROM anfasst: erst beweisen, dass das Modul wirklich kaputt ist - DDM-Temperatur, Spannung, Bias-Strom und TX/RX-Leistung aus A0h/A2h auslesen, Verriegelungen, Kontakte und Linsen reinigen, ein nachweislich funktionierendes Modul zum Testen einstecken und den Link mit iperf3 unter Last testen. Die Hälfte der Module, die angeblich neu geflasht werden müssen, braucht nur eine Reinigung.
Wer lieber zahlt als lötet: Die kommerziellen Boxen kommen mit ihren eigenen Fallstricken. Die FS Box codiert sauber um, Leute haben so FS-SFP-GE-BX-Module an einer Intel X710 mit Autoselect zum Laufen gebracht, aber sie programmiert nur FS-Module, und ein Nicht-FS-Modul einzustecken hat Nutzern schon wochenlange Account-Sperren eingebracht.