Herramientas abiertas para EEPROM de transceptores más allá de ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Una buena mitad de mi trabajo es poner la óptica de una empresa en el switch de otra, así que paso mucho tiempo preguntándole a un módulo qué cree que es. Mi caja de herramientas para eso hoy tiene un solo comando de profundidad, y me gustaría saber qué más vale la pena poner en la máquina de banco.

• equipos Linux con puertos SFP+ y QSFP28 para trabajo de banco, más una Raspberry Pi sin hacer nada útil
• un switch de laboratorio corriendo SONiC, y lo que sea de CLI de fabricante que tenga el equipo del cliente
• un cajón de módulos desde SFP hasta QSFP-DD, la mayoría codificados para otra persona

Lo que uso hoy:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Del lado del fabricante es lo que sea que ofrezca el equipo - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Todo eso lee. Nada escribe, y nada me dice si un checksum realmente está mal o simplemente es inusual.

Lo que he encontrado pero aún no he usado en serio:

• sfppi, un programador I2C para la Raspberry Pi que también corrige checksums
• sfpdoctor y py-sfp-eeprom para leer y modelar las páginas SFF-8472
• OCP oom, la biblioteca abierta de monitoreo óptico orientada a switches, y el driver optoe sobre el que se apoya sfputil

Las cajas comerciales de codificación son una decisión aparte y no la que estoy preguntando. Lo que quiero primero es qué herramientas abiertas la gente realmente mantiene en un banco: qué lee una página de forma confiable entre distintos formatos, con qué es seguro escribir, y dónde está el límite entre las piezas SFF-8472 y las CMIS en el mismo cajón.

¿Alguien ha armado una rutina de trabajo con estas, o sigue siendo una herramienta por tarea?