ethtool -m से आगे transceiver EEPROMs के लिए open tooling: sfppi, sfpdoctor, py-sfp-eeprom, oom

मेरे काम का अच्छा-ख़ासा आधा हिस्सा एक company के optics को दूसरी company के switch में लगाना है, तो मैं काफ़ी वक़्त किसी module से यह पूछने में बिताता हूं कि वह खुद को क्या समझता है। इसके लिए मेरा toolbox फ़िलहाल एक command जितना गहरा है, और मैं जानना चाहता हूं कि bench machine पर और क्या रखने लायक है।

• bench काम के लिए SFP+ और QSFP28 ports वाले Linux boxes, साथ ही एक Raspberry Pi जो कुछ काम का नहीं कर रहा
• SONiC चलाता एक lab switch, और customer के kit में जो भी vendor CLI मिल जाए
• SFP से लेकर QSFP-DD तक modules से भरी एक drawer, ज़्यादातर किसी और के लिए coded

आज मैं जो इस्तेमाल करता हूं:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Vendor साइड पर जो भी box देता है वह चलता है - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor। यह सब पढ़ता है। इनमें से कुछ भी लिखता नहीं, और कोई भी यह नहीं बताता कि कोई checksum असल में गलत है या बस असामान्य है।

जो मुझे मिला है पर अभी गुस्से में इस्तेमाल नहीं किया:

• sfppi, Raspberry Pi के लिए एक I2C programmer जो checksums भी ठीक कर देता है
• SFF-8472 pages पढ़ने और model करने के लिए sfpdoctor और py-sfp-eeprom
• OCP oom, switches के लिए बना open optical monitoring library, और optoe driver जिस पर sfputil टिका है

Commercial coder boxes एक अलग फ़ैसला हैं, और वह वह सवाल नहीं जो मैं पूछ रहा हूं। पहले मुझे यह जानना है कि लोग bench पर असल में कौन से open tools रखते हैं: कौन सा हर form factor में भरोसे से page पढ़ता है, किसके साथ लिखना सुरक्षित है, और उसी drawer में SFF-8472 वाले parts और CMIS वालों के बीच boundary कहां पड़ती है।

क्या किसी ने इनसे मिलाकर working routine बनाया है, या अब भी एक काम के लिए एक ही tool चलता है?