Ferramentas abertas para EEPROMs de transceptores além do ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Boa parte do meu trabalho é colocar óptica de uma empresa no switch de outra empresa, então eu passo bastante tempo perguntando a um módulo o que ele acha que é. Minha caixa de ferramentas para isso hoje tem um comando de profundidade, e eu queria saber o que mais vale a pena ter na máquina de bancada.

• máquinas Linux com portas SFP+ e QSFP28 para trabalho de bancada, mais um Raspberry Pi sem fazer nada útil
• um switch de laboratório rodando SONiC, e qualquer CLI de vendor que o equipamento do cliente tiver
• uma gaveta de módulos de SFP até QSFP-DD, a maioria codificada para outra empresa

O que eu uso hoje:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Do lado do vendor é o que a caixa oferecer - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Tudo isso lê. Nada disso grava, e nada disso me diz se um checksum está realmente errado ou só é incomum.

O que eu já achei mas ainda não usei pra valer:

• sfppi, um programador I2C para o Raspberry Pi que também corrige checksums
• sfpdoctor e py-sfp-eeprom para ler e modelar páginas SFF-8472
• OCP oom, a biblioteca aberta de monitoramento óptico voltada a switches, e o driver optoe em que o sfputil se apoia

As caixas comerciais de codificação são uma decisão separada, e não é essa que estou perguntando. O que eu quero primeiro é quais dessas ferramentas abertas o pessoal realmente mantém numa bancada: o que lê uma página de forma confiável entre form factors, o que é seguro pra gravar, e onde fica a fronteira entre as peças SFF-8472 e as CMIS na mesma gaveta.

Alguém já montou uma rotina funcional com essas ferramentas, ou ainda é uma ferramenta por tarefa?