SONiC dekodiert ein CMIS-4.0-QSFP-DD in verstümmelte Vendor-Felder, während SFF-Module sauber geparst werden

Auf welchem Branch bist du? Es gibt bekannte Inkonsistenzen bei Key-Namen zwischen show interfaces transceiver eeprom und sfputil in 202012, die in 202205 bereinigt wurden, das lohnt sich auszuschließen, bevor man tiefer gräbt.

Poste die Ausgabe von sudo sfputil show eeprom -d für denselben Port. Wenn sfputil dieselben verstümmelten Strings liefert, liegt der Fehler im gemeinsamen Decode-Pfad. Wenn es stattdessen mit einem Fehler abbricht, bist du in anderem Terrain - wir haben Plattformen, wo einfach nur Cannot get Module EEPROM data: Invalid argument kommt und gar nichts erst zum Dekodieren kommt.

Beides ausgeführt: sudo sfputil show eeprom -d und show interfaces transceiver eeprom -d am selben Port. Identische Verstümmelung, dieselben Felder, derselbe Müll, wo die Seriennummer stehen sollte. Nirgends ein Invalid argument, das Auslesen selbst läuft anstandslos durch.

Die beiden Befehle stimmen also überein, sie stimmen nur bei der falschen Antwort überein. Benachbarte QSFP28-Ports bleiben bei beiden sauber, das sieht also eher nach diesem spezifischen CMIS-Teil aus als nach der Plattform.

Dieses Muster ist die Signatur eines Parsers, der auf eine Memory-Map angewendet wird, die er nicht versteht: eine Teilenummer, die im Vendor-Name-Feld sitzt, eine unlesbare Seriennummer, Connector und Encoding verschoben. Ein kaputtes Modul oder ein kaputter I2C-Read liefert dir einen Fehler oder einen Block aus Nullen, keine sauber falschen Strings.

Der Decode-Pfad sitzt in sonic_platform_base/sonic_sfp/sfputilbase.py, und dort werden die drei Identitätsstrings aus Offsets herausgezogen, die fest gegen die alte SFF-Map codiert sind, egal was tatsächlich steckt. Ein CMIS-4.0-QSFP-DD hält seinen Identitätsblock nicht an diesen Adressen - die CMIS-4.0-Spec beschreibt das in Abschnitt 8.3 -, der Code liest also echte Bytes aus dem richtigen Modul, nur nicht die, die er zu lesen glaubt, und gibt aus, was auch immer in diesem Bereich liegt. Das ist auch, warum nie etwas sauber fehlschlägt: Kein Schritt schaut sich das Identifier-Byte an und wechselt auf ein CMIS-Layout.

Die praktische Schlussfolgerung ist, dass nichts unterhalb eines Parsers, der die CMIS-Map versteht, das hier richtig hinbekommt, und bis das in deinem Branch landet, ist die CLI-Ausgabe für dieses Teil nicht inventar-tauglich. Für die Asset-Datenbank die Seiten roh lesen und selbst dekodieren, statt die CLI abzugrasen.

Für den Rohzugriff willst du den optoe-Treiber: Er legt SFP-, QSFP- und CMIS-EEPROMs zum direkten Lesen und Schreiben offen, du kannst also die Bytes ziehen und in deinem eigenen Skript dekodieren. Das ist im Moment das Einzige, was ich für CMIS-Teile in eine Asset-Datenbank füttern würde.

Eine Warnung, falls du nach Offsets suchst. Die Tabelle, die alle zitieren, ist die SFF-Tabelle - A0h Bytes 20-35 für den Vendor-Namen, 40-59 für PN, Rev und SN. Das sind genau die Offsets, die dir bei einem CMIS-Modul den Müll erzeugen, also dort nicht wiederverwenden. Gleiche Vorsicht bei einem Linux-Host als Bench-Tool: ethtool -m für die dekodierte Ansicht und ethtool -e für rohe Bytes sind bei SFP-Teilen in Ordnung, aber prüf, was dein Build tatsächlich versteht, bevor du den Feldern traust, die er für CMIS ausgibt.

CMIS-Handling ist an mehr Stellen dünn als nur im EEPROM-Decoder. Wir haben ein Tray InnoLight-800G-QSFP-DD-Optik in Betrieb genommen, T-DP8CNH-NNO und T-DP8CNT-NNO, und etwa jedes zweite Einstecken ließ uns mit einem toten Port zurück: Datapaths meldeten DataPathDeactivated, im Log stand ein Timeout für 'ConfigSuccess', und von da an war der Port dauerhaft down - kein Retry, nichts, das sich von selbst erholt hätte.

Der Übeltäter erwies sich als decommission_all_datapaths() in cmis.py. Sie geht die ganze Sequenz Schritt für Schritt durch - DEINIT, Application ID auf 0 gelöscht, dann INIT - und prüft nie, ob ein Schritt tatsächlich gegriffen hat, bevor der nächste beginnt. Unsere Teile brauchen genau diese Bestätigung, der Datapath bleibt also halb konfiguriert, und die State Machine sitzt einfach ihren Timer ab. Ein echter Fix muss asynchron warten, denn man kann innerhalb der inline CMIS State Machine von xcvrd nicht blockieren, und als ich zuletzt nachgesehen habe, hatte das noch niemand gelandet. Anderer Bug, gleiches Thema: ein CMIS-Pfad, der auf Code für SFF-Teile draufgeschraubt wurde.

Eine Korrektur zu der Richtung, in die das hier abdriftet, denn die beiden Fehlerarten werden ständig durcheinandergeworfen. Cannot get Module EEPROM data: Invalid argument, oder ein QSFP, das nach einem Power Cycle aus sfputil verschwindet, bis der Treiber gefixt ist, oder eine Plattform, die get_transceiver_info schlicht nicht implementiert - das sind Plattform- und Treiberlücken, und sie stoppen dich, bevor überhaupt dekodiert wird.

Was hier beschrieben wird, ist das Gegenteil: ein vollständiges, erfolgreiches Auslesen, das anschließend mit dem falschen Feld-Layout interpretiert wird. Deswegen keine Module tauschen oder Treiberversionen hinterherjagen. Die Bytes in diesem Modul sind in Ordnung, und jedes Tool, das sie als CMIS dekodiert, zeigt dir die Seriennummer vom Label.