Otwarte narzędzia do EEPROM-ów transceiverów poza ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Dobra połowa mojej pracy to wpinanie optyki jednej firmy w switch innej firmy, więc sporo czasu spędzam, pytając moduł, za co się uważa. Mój zestaw narzędzi do tego ma dziś głębokość jednej komendy i chciałbym wiedzieć, co jeszcze warto postawić na maszynie testowej.

• maszyny z Linuksem z portami SFP+ i QSFP28 do pracy na stole, plus Raspberry Pi, które nic pożytecznego nie robi
• switch laboratoryjny z SONiC i jakiekolwiek CLI vendora akurat ma sprzęt klienta
• szuflada modułów od SFP po QSFP-DD, w większości zakodowanych dla kogoś innego

Czego używam dziś:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Po stronie vendora to, co akurat oferuje dane pudełko - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Wszystko to czyta. Nic z tego nie zapisuje i nic nie mówi, czy suma kontrolna jest naprawdę błędna, czy tylko nietypowa.

Co znalazłem, ale jeszcze nie użyłem na poważnie:

• sfppi, programator I2C do Raspberry Pi, który przy okazji naprawia sumy kontrolne
• sfpdoctor i py-sfp-eeprom do odczytu i modelowania stron SFF-8472
• OCP oom, otwarta biblioteka do monitoringu optyki nastawiona na switche, oraz sterownik optoe, na którym siedzi sfputil

Komercyjne pudełka do kodowania to osobna decyzja i nie to, o co pytam. Najpierw chcę wiedzieć, które z otwartych narzędzi ludzie faktycznie trzymają na stole: co czyta stronę niezawodnie niezależnie od obudowy, czym bezpiecznie pisać, i gdzie leży granica między częściami SFF-8472 a tymi CMIS w tej samej szufladzie.

Czy ktoś zbudował z tego działającą rutynę, czy to wciąż jedno narzędzie na jedno zadanie?