Welche EEPROM-Prüfsummen müssen nach dem Ändern von Herstellername und PN in einem SFP-Image neu berechnet werden
Werkstattarbeit: Ein kleines Batch SFP+-Module wird umcodiert, damit sie den Herstellerstring und die Teilenummer tragen, die das Kit des Kunden erwartet. Die Änderung selbst ist im Hex-Editor trivial, der Schreibvorgang geht durch, das Rücklesen stimmt Byte für Byte mit dem Geschriebenen überein - und der Host wirft das Modul trotzdem raus.
- generische SFP+-Module, A0-Seite von Hand editiert
- CH341-basierter Programmer mit dem mitgelieferten Tool
- editierte Felder: Herstellername und Vendor-PN, sonst nichts angefasst
- ein unveränderter Dump, auf dasselbe Modul zurückgeschrieben, funktioniert einwandfrei - der Schreibpfad selbst ist also nicht das Problem
Was ich nach der Änderung verglichen habe:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorDie Summenbytes haben sich also eindeutig nicht mitbewegt, als sich der Payload geändert hat. Bevor ich mir dafür eigenes Tooling schreibe: Welche Byte-Bereiche decken diese beiden Summen tatsächlich ab, sind es einfache additive Summen oder etwas CRC-Artiges, und gibt es ein gepflegtes Utility, das sie neu berechnet, damit ich nicht bei jedem Modul von Hand rechnen muss?
Comments 4
Dein Programmer macht genau das, was CH341-basierte Tools normalerweise machen: nichts. Sie schreiben die Bytes, die man ihnen übergibt, und rühren die Prüfsummenfelder nie an. Hersteller-Programmer berechnen beim Schreiben neu, weshalb Leute, die nur diese benutzen, das Problem nie zu Gesicht bekommen und überzeugt sind, das ganze Thema sei erfunden.
Zwei Dinge sind es wert, geklärt zu werden, bevor du irgendein Tooling schreibst. Erstens: Was hat das Image nach dem Schreiben zurückgelesen - dasselbe Tool, das geschrieben hat, oder etwas Unabhängiges? Ein Reader, der dir seinen eigenen Cache serviert, zeigt bereitwillig ein Byte, das nie im Chip gelandet ist. Zweitens: Hast du die Summe über die Bytes 0 bis 62 des editierten Images selbst ausgerechnet und mit Byte 63 verglichen, oder vergleichst du Byte 63 nur mit dem Original-Dump? Unverändert und korrekt sind nicht derselbe Test, und deine Notizen zeigen nur den ersten.
Auch wert, genannt zu werden: der Host, der es ablehnt. Manche lesen die Identitätsfelder und prüfen gar nichts, andere validieren streng und werfen das Modul raus, sobald eine Summe nicht stimmt. Gleiches Image, unterschiedliches Urteil.
Es gibt genau zwei davon, und es sind simple 8-Bit-Summen, CRC kommt nirgendwo vor.
Herstellername und Vendor-PN liegen beide im Base-Bereich, deine Änderung hat also CC_BASE ungültig gemacht, während CC_EXT zu Recht korrekt blieb. Änderungen an Seriennummer und Datumscode treffen dagegen den erweiterten Bereich, dann ist es Byte 95, das veraltet. Beides neu zu berechnen sind zwei Zeilen über dem Buffer: Bereich aufsummieren, mit 0xFF maskieren, ins Summenbyte schreiben.
Wer das nicht von Hand machen will, für den gibt es Tooling. py-sfp-eeprom baut und validiert EEPROM-Images aus Python heraus (
python3 -m sfp_eeprom), undsfppiläuft auf einem Raspberry Pi, prüft die Summen und bietet an, sie zu reparieren. Beides ist die bessere Gewohnheit als Hex-Editor plus Kopfrechnen, weil der Fehlermodus lautlos ist - das Modul liest exakt das zurück, was geschrieben wurde, und nur der Host beschwert sich.Die beiden MSA-Summen richtig hinzubekommen ist notwendig und, je nachdem an wessen Port man steckt, nicht ausreichend.
Cisco ist das altbekannte Beispiel: Die Identitätsprüfung besteht nicht nur aus den Strings. Jemand hat vor Jahren herausgefunden, dass sich der Wert, den ein Cisco-codiertes Modul trägt, mit nichts Exotischerem als
xxd -r -p | md5sumreproduzieren lässt, gefüttert mit dem Vendor-Code-Byte und dann den Namensbytes. In diesen Dumps sind Code und Name aneinander gekoppelt - Finisar steckt hinter 02, Methode hinter 0E. Stimmen die beiden nicht überein, spuckt ein Catalyst 2960X das Modul wieder aus, mit oder ohne Unlock-Befehle.Das ist meistens der Grund, warum ein von einem funktionierenden Modul kopierter Dump aufhört zu funktionieren, sobald jemand einen anderen Herstellerstring hineingepastet hat. Die Summen stimmen, die Identität ist nur nicht mehr in sich konsistent.
Kleine Korrektur zum Rahmen "die beiden Summen fixen und fertig": Das gilt für die MSA-Felder, nicht für das, was jeder Hersteller unter einem gültigen Image versteht.
HP ist das Standard-Gegenbeispiel. Die Seriennummer in einem J4858B-Image ändern, Byte 68 bis 83, und auch Byte 124 bis 127 von A0 ändern sich mit - eine Herstellerprüfsumme, die hinter den MSA-Bytes CC_BASE und CC_EXT sitzt. Das wurde ausführlich durchgekaut, und niemand hat je den Algorithmus veröffentlicht; man hat bestätigt, dass die Bytes eine Rolle spielen, und dabei endete der Thread. Dieselbe Geschichte wurde rund um J4859C und J9150A berichtet. Spätere HP- und Aruba-Geräte sind auf ein Challenge-Response-Verfahren (HPIDv2) umgestiegen, das sich in einem EEPROM überhaupt nicht fälschen lässt.
Bevor du also in Tooling investierst: Kläre, was der Ziel-Host validiert - zwei additive Summen bei einem einfachen Host, eine in sich konsistente Identität bei Catalyst, und bei manchen HP-Teilen ein undokumentiertes Feld, das du nicht reproduzieren wirst.