CodingBox Q&A Ask question

Open tooling for transceiver EEPROMs beyond ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Asked Active Viewed 30 Original language: English
0

A good half of my work is putting one company's optics into another company's switch, so I spend a lot of time asking a module what it thinks it is. My toolbox for that is currently one command deep, and I would like to know what else is worth putting on the bench machine.

  • Linux boxes with SFP+ and QSFP28 ports for bench work, plus a Raspberry Pi doing nothing useful
  • a lab switch running SONiC, and whatever vendor CLI the customer kit happens to have
  • a drawer of modules from SFP through QSFP-DD, most of them coded for somebody else

What I use today:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

On the vendor side it is whatever the box offers - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. All of that reads. None of it writes, and none of it tells me whether a checksum is actually wrong or just unusual.

What I have found but not yet used in anger:

  • sfppi, an I2C programmer for the Raspberry Pi that also fixes checksums
  • sfpdoctor and py-sfp-eeprom for reading and modelling SFF-8472 pages
  • OCP oom, the open optical monitoring library aimed at switches, and the optoe driver that sfputil sits on

The commercial coder boxes are a separate decision and not the one I am asking about. What I want first is which of the open tools people actually keep on a bench: what reads a page reliably across form factors, what is safe to write with, and where the boundary sits between the SFF-8472 parts and the CMIS ones in the same drawer.

Has anyone built a working routine out of these, or is it still one tool per task?

Comments 0

No comments yet.

Log in to comment. Log in