SONiC decodes a CMIS 4.0 QSFP-DD into garbled vendor fields while SFF modules parse fine

Which branch are you on? There are known key-name inconsistencies between show interfaces transceiver eeprom and sfputil in 202012 that were sorted out in 202205, and it is worth ruling that out before digging deeper.

Post the output of sudo sfputil show eeprom -d for the same poort. If sfputil gives you the same mangled strings, the fault is in the shared decode path. If it errors out instead, you are in differrent territory - we have platforms where it just answers Cannot get Module EEPROM data: Invalid argument and never gets as far as decoding anything.

Ran both: sudo sfputil show eeprom -d and show interfaces transceiver eeprom -d on the same port. Identical mangling, same fields, same garbage where the serial should be. No Invalid argument anywhere, the read itself goes through without complaint.

So the two commands agree with each other, they just agree on the wrong answer. Neighbouring QSFP28 ports stay clean through both, which makes it look specific to this CMIS part rather than to the platform.

That pattern is the signature of a parser applied to a memory map it does not understand: a part number sitting in the vendor name field, an unreadable serial, connector and encoding shifted. A broken module or a broken I2C read gives you an error or a block of zeros, not neatly wrong strings.

The decode path lives in sonic_platform_base/sonic_sfp/sfputilbase.py, and there the three identity strings are lifted from offsets hardcoded against the legacy SFF map, whatever happens to be plugged in. A CMIS 4.0 QSFP-DD does not keep its identity block at those addresses - the CMIS 4.0 spec describes it in section 8.3 - so the code is reading genuine bytes out of the right module, just not the ones it believes it is readig, and it prints whatever occupies that range. That is also why nothing ever fails cleanly: no step looks at the identifier byte and switches to a CMIS layout.

The practical conclusion is that nothing short of a parser which understands the CMIS map will get this right, and until that lands in your branch the CLI output for this part is not inventory-grade. For the asset database, read the pages raw and decode them yourself rather thn scraping the CLI.

For the raw read, the optoe driver is what you want: it exposes SFP, QSFP and CMIS EEPROMs for direct read and write, so you can pull the bytes and decode them in your own script. That is the only thing I would feed an asset database for CMIS parts at the moment.

One warning if you go looking for offsets. The table everyone quotes is the SFF one - A0h bytes 20-35 for the vendor name, 40-59 for PN, rev and SN. Those are exactly the offsets that produce your garbage on a CMIS module, so do not reuse them there. Same caution on a Linux host as a bench tool: ethtool -m for the decoded view and ethtool -e for raw bytes are fine for SFP parts, but check what your build actually understands before trusting the fields it prints for CMIS.

CMIS handling is thin in more places than the EEPROM decoder. We put a tray of InnoLight 800G QSFP-DD optics into service, T-DP8CNH-NNO and T-DP8CNT-NNO, and about every second insertion left us with a dead port: datapaths reported DataPathDeactivated, the log carried a timeout for 'ConfigSuccess', and from there the port was down permanently - no retry, nothing that brought it back on its own.

The culprit turned out to be decommission_all_datapaths() in cmis.py. It walks the whole sequence back to back - DEINIT, application ID cleared to 0, then INIT - and never checks that a step actually took effect before starting the next one. Our parts need exactly that confirmation, so the datapath is left half-configured and the state machine simply sits out its timer. A real fix has to wait asynchronously, since you cannot block inside xcvrd's inline CMIS state machine, and last I checked nobody had landed one. Different bug, same theme: a CMIS path bolted onto code written for SFF parts.

One correction to the direction this is drifting in, because the two failure modes get mixed up constantly. Cannot get Module EEPROM data: Invalid argument, or a QSFP vanishing from sfputil after a power cycle until the driver is fixed, or a platform that simply does not implement get_transceiver_info - those are platform and driver gaps, and they stop you before any decoding happens.

What is described here is the opposite: a complete, successful read that is then interpreted with the wrong field layout. Do not swap modules or chase driver versions over it. The bytes inside that module are fine, and any tool that decodes them as CMIS will show you the serial on the label.