Offene Werkzeuge für Transceiver-EEPROMs jenseits von ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Gut die Hälfte meiner Arbeit besteht darin, die Optik einer Firma in den Switch einer anderen zu stecken, ich verbringe also viel Zeit damit, ein Modul zu fragen, was es zu sein glaubt. Meine Toolbox dafür ist momentan einen Befehl tief, und ich würde gern wissen, was sonst noch auf die Werkbank-Maschine gehört.

• Linux-Boxen mit SFP+- und QSFP28-Ports für die Werkbank, dazu ein Raspberry Pi, der nichts Nützliches tut
• ein Lab-Switch mit SONiC, und was auch immer für eine Vendor-CLI das Kundengerät gerade hat
• eine Schublade voller Module von SFP bis QSFP-DD, die meisten für jemand anderen codiert

Was ich heute benutze:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Auf der Vendor-Seite ist es, was die Box gerade anbietet - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Das liest alles. Nichts davon schreibt, und nichts davon sagt mir, ob eine Checksumme tatsächlich falsch ist oder nur ungewöhnlich.

Was ich gefunden, aber noch nicht im Ernstfall benutzt habe:

• sfppi, ein I2C-Programmer für den Raspberry Pi, der auch Checksummen repariert
• sfpdoctor und py-sfp-eeprom zum Lesen und Modellieren von SFF-8472-Seiten
• OCP oom, die offene Optical-Monitoring-Bibliothek für Switches, und der optoe-Treiber, auf dem sfputil sitzt

Die kommerziellen Coder-Boxen sind eine separate Entscheidung und nicht die, nach der ich frage. Was ich zuerst wissen will, ist, welche der offenen Werkzeuge Leute tatsächlich auf einer Werkbank behalten: was eine Seite zuverlässig über Formfaktoren hinweg liest, womit man gefahrlos schreiben kann, und wo die Grenze zwischen den SFF-8472-Teilen und den CMIS-Teilen in derselben Schublade verläuft.

Hat schon mal jemand daraus eine funktionierende Routine gebaut, oder ist es immer noch ein Werkzeug pro Aufgabe?