Outils ouverts pour les EEPROM de transceivers au-delà d'ethtool -m : sfppi, sfpdoctor, py-sfp-eeprom, oom

Une bonne moitié de mon travail consiste à mettre les optiques d'une entreprise dans le switch d'une autre, donc je passe beaucoup de temps à demander à un module ce qu'il pense être. Ma boîte à outils pour ça ne fait actuellement qu'une commande de profondeur, et j'aimerais savoir quoi d'autre vaut la peine d'être installé sur la machine de banc.

• des machines Linux avec des ports SFP+ et QSFP28 pour le travail de banc, plus un Raspberry Pi qui ne fait rien d'utile
• un switch de labo sous SONiC, et quel que soit le CLI vendeur présent sur le matériel client
• un tiroir de modules allant du SFP au QSFP-DD, la plupart codés pour quelqu'un d'autre

Ce que j'utilise aujourd'hui :

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Côté vendeur, c'est ce que le boîtier propose - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Tout cela lit. Rien de tout cela n'écrit, et rien ne me dit si une somme de contrôle est réellement erronée ou juste inhabituelle.

Ce que j'ai trouvé mais pas encore utilisé pour de vrai :

• sfppi, un programmateur I2C pour Raspberry Pi qui corrige aussi les sommes de contrôle
• sfpdoctor et py-sfp-eeprom pour lire et modéliser les pages SFF-8472
• OCP oom, la bibliothèque ouverte de surveillance optique destinée aux switchs, et le pilote optoe sur lequel repose sfputil

Les boîtiers de codage commerciaux sont une décision à part et ce n'est pas ce que je demande ici. Ce que je veux d'abord, c'est quels outils ouverts les gens gardent réellement sur un banc : ce qui lit une page de façon fiable quel que soit le facteur de forme, ce qu'il est sûr d'utiliser pour écrire, et où se situe la frontière entre les pièces SFF-8472 et les pièces CMIS dans le même tiroir.

Quelqu'un a-t-il construit une routine de travail fonctionnelle à partir de tout ça, ou est-ce encore un outil par tâche ?