programmer खरीदने की बजाय Raspberry Pi के I2C bus से SFP EEPROM पढ़ना और दोबारा लिखना
घर पर मैं निकाले हुए SFPs की एक shelf रखता हूं और चाहता हूं कि इनका EEPROM पढ़ सकूं, किसी ऐसे module को ठीक कर सकूं जिसका checksum गड़बड़ हो गया हो, और कभी-कभार किसी ऐसे switch के लिए एक recode कर सकूं जो vendor strings को लेकर नखरे करता है। साल में मुट्ठी भर modules के लिए commercial programmer खरीदना यहां कोई मतलब नहीं रखता, तो मैं यह पता लगाने की कोशिश कर रहा हूं कि खुद बनाया हुआ rig असल में कहां तक जाता है।
Bench पर जो है:
- Raspberry Pi, जिसका I2C bus मैंने खुद wire की हुई SFP cage तक निकाला है
- एक BIOS वाले काम से बचा हुआ CH341A USB programmer board
- 1G और 10G SFP/SFP+ modules का मिला-जुला ढेर, साथ में दो QSFP+ वाले भी जिन्हें मैं देखना चाहूंगा
Reads कम से कम इस मायने में काम करते हैं कि bus पर कुछ जवाब देता है:
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
$ i2cdump -y 1 0x50अब तक जो किया:
- A0h हाथ से dump किया और bytes को SFF-8472 field offsets से compare किया, जो धीमा है और गलत होना आसान
- CH341A से कुछ bytes लिखे: वो चले जाते हैं, पर मेरे लिए checksums कोई recalculate नहीं करता, तो जब तक मैं खुद patch न करूं module कचरा वापस आता है
- QSFP+ modules को बिना छेड़े रखा, क्योंकि जो cage मैंने बनाई वो सिर्फ SFP लेती है
तो इसके लिए open tooling असल में दिखती कैसी है: क्या कुछ ऐसा है जो memory layout जानता हो, write के बाद checksum bytes verify करे, और एक QSFP+ slot भी drive कर सके? और घर पर बना rig कहां जाकर काफी नहीं रह जाता?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
plain SFP/SFP+ काम के लिए Pi काफी है। module बस दो I2C devices है, जो ठीक वही है जो आपका i2cdetect output 0x50 और 0x51 पर दिखाता है, और उससे आगे कोई जादू नहीं होता। जो चीज़ आपको byte गिनने से बचाती है वो sfppi है: यह Pi का I2C bus drive करता है, fields आपके लिए decode करता है, और CC_BASE व CC_EXT check करके write के बाद उन्हें ठीक करने का offer भी देता है। यही ठीक वो step है जो CH341A आपके लिए नहीं करता। CH341A बेकार नहीं है, यह पढ़ता और लिखता ठीक है, बस इसे पता नहीं होता कि bytes का मतलब क्या है, तो हर checksum आपकी problem बना रहता है।
QSFP+ के लिए आपकी soldered cage काम नहीं आएगी। community जिस design की तरफ इशारा करता है वो है Hubble, एक open programmer जिसमें SFP वाले के बगल में एक QSFP slot भी है, तो अगर उन दो modules को छूना है तो यही दिशा है। एक barebones Reveltronics build भी है जो उन modules पर write passwords brute-force करने के लिए इस्तेमाल होता है जो writes को सिरे से मना कर दें। मुझे खुद कभी उसकी ज़रूरत नहीं पड़ी, तो इसे बस एक इशारा मानो और ऐसे hardware पर check करो जिसे खोने का बर्दाश्त कर सको।
यह उससे मेल खाता है जो मुझे यहां दिखता है। दूसरा page भी live है, तो memory के दोनों हिस्से पढ़ने के लिए मौजूद हैं:
मैं cage की wiring ठीक से दोबारा करूंगा और फिर जो कुछ रखना चाहता हूं उसे छूने से पहले किसी ऐसे module पर checksum वाला रास्ता try करूंगा जिसकी परवाह नहीं। QSFP+ अभी के लिए रुका रहेगा, साल में दो modules के लिए दूसरी cage बनाना justify करना मुश्किल है, तो वो तब तक read-only रहेंगे जब तक मैं तय नहीं करता कि Hubble मेहनत के लायक है या नहीं।
price range के दूसरे छोर से इसमें जोड़ता हूं, क्योंकि हर कोई अपना नहीं बनाता: रोज़मर्रा इस्तेमाल में जो tools दिखते हैं वो हैं SNR SFP Writer, SFPTotal Plus series, और CH341 boards के इर्द-गिर्द बने कई one-off devices, जो वही chip है जो आपके पास bench पर पहले से है।
गहराई में जाने से पहले जानने लायक बात यह है कि हर module plain EEPROM नहीं होता। कुछ में अपना microcontroller होता है जो असली chip दिखाने की बजाय A0/A2 memory को emulate करता है, जिसमें अंदर C8051F392 वाला एक Medick SFP-10G-BX वो उदाहरण है जो बार-बार आता है। वो write passwords या vendor challenges implement कर सकते हैं, और bus को कितना भी कुरेद लो वो उन्हें dumb EEPROM में नहीं बदलता। सबसे गंदा case जो लोग उठाते हैं वो है keys वाला HP/Aruba interactive EEPROM।
अपनी cage के लिए एक practical बात: pinout सही रखो वरना भूत पकड़ते रह जाओगे। TX_Disable pin 3 है, Mod_Abs pin 6 है, VeeR pin 9 है। खासकर Mod_Abs ही तय करता है कि कोई भी चीज़ यह मानती भी है या नहीं कि module मौजूद है।
और इसका risk वाला पहलू, क्योंकि इसका ज़िक्र तभी होता है जब किसी का module मर चुका होता है। बहुत सारे modules write accept करने से पहले 4-byte password मांगते हैं। इनमें से ज़्यादातर passwords सार्वजनिक रूप से घूम रहे हैं और कोई universal utility नहीं है, तो आप vendor-specific tools और firmware databases या manufacturer से खींची images के एक ढेर पर आ जाते हो। इनमें से कुछ भी गलत करो और आपने ऐसा module brick कर दिया जो programmer से भी महंगा था।
तो EEPROM को छूने से बिल्कुल पहले, यह साबित करो कि module असल में खराब है: A0h/A2h से DDM temperature, voltage, bias current और TX/RX power पढ़ो, latches, contacts और lenses साफ करो, एक known-good module लगाकर देखो, और iperf3 से link का load-test करो। जिन modules को माना जाता है कि reflash चाहिए उनमें से आधे को बस सफाई चाहिए होती है।
अगर solder करने की बजाय पैसे देना पसंद है, तो जान लो कि commercial boxes अपनी शर्तों के साथ आते हैं। FS Box अच्छे से recode करता है, लोगों ने इसी तरह Intel X710 पर autoselect के साथ FS SFP-GE-BX modules काम करवाए, पर यह सिर्फ FS modules ही program करता है और non-FS module डालने पर users को हफ्ते भर के account lockouts झेलने पड़े हैं।