Programmer SFP+ FTLX8571D3BCV-IT पढ़ लेता है, पर लिखने पर No Acknowledge देता है
शहर भर में बिखरे नोड्स के लिए modules का एक छोटा exchange fund रखता हूं, और लगभग हर किसी दूसरे के switch के लिए SFP recode करना पड़ता है। gigabit modules के साथ तरीका बहुत पहले से सध चुका है, पर दस gig वाले पर अटक गया।
table पर क्या है:
- SFP/SFP+ के लिए cage वाला programmer, 3.3 V power
- Finisar FTLX8571D3BCV-IT और FTLX1471D3BCV-IT, दोनों पढ़े जाते हैं
- पुराने stock से Cisco GLC-LH-SM
- HP J4858B और J4859C
Read स्थिर और repeatable तरीके से निकलता है, दोनों banks पूरे के पूरे। Write किसी भी variant में नहीं जाता:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledgeअब तक जो check किया:
- वही operations उसी programmer से आम gigabit SFP पर हो जाते हैं, यानी circuit और power ज़िंदा हैं;
- FTLX8571D3BCV-IT का दूसरा नमूना लिया, व्यवहार byte-दर-byte वैसा ही है;
- GLC-LH-SM पर No Acknowledge vendor fields को छूने की कोशिश से भी पहले, तुरंत आ जाता है।
मतलब मामला किसी एक नमूने का नहीं है। क्या यह खुद module के अंदर हार्डवेयर write protection है, या SFP+ में memory अब सादा EEPROM नहीं रही और साधारण I2C write से वहां पहुंचा ही नहीं जा सकता? और अलग से यह जानना है कि HP J4858B/J4859C: इन्हें कोई साधारण programmer से लिखता है, या यह पहले से तय dead end है?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
यहां दो अलग mechanisms मिल गए हैं, और इनका इलाज भी अलग-अलग है।
पहला - अपनी हार्डवेयर write protection वाली आम EEPROM। memory chip पर एक write protect pin होता है, और जब तक वो pulled-up है, read चलता रहता है पर write गिर जाता है। जो तरीका इसमें गहराई से लगे लोगों ने बताया वो है: flashing के दौरान उस pin को ground पर बैठा दो। कुछ gigabit modules के लिए इतना ही काफी है।
दूसरा - वो जिससे तुम दस gig वाले पर टकराए हो। SFP+ में data अक्सर अलग EEPROM में नहीं, बल्कि module के microcontroller के पीछे बैठा होता है: वो खुद A0 और A2 read के लिए देता है और write सिर्फ अपनी command sequence से ही स्वीकार करता है। standard programmer ऐसी sequence जानता ही नहीं और किसी भी कोशिश पर No Acknowledge पाता है, चाहे तुम किसी भी field को निशाना बनाओ। वहां ground करने को कुछ है ही नहीं।
cage को bypass करने में जो असल में मदद करता है: सीधे module के pin 4 और 7 पर, यानी I2C की lines पर, programmer के connector को छोड़कर तार से solder करना। सुनने में आता है कि इसके बाद कुछ ऐसे modules भी लिखे जाते हैं जो cage में चुप रहते थे। तरीका खुरदरा है, हाथ साफ चाहिए, और इसके बाद module तुम्हारी अपनी जिम्मेदारी पर जीता है।
HP अलग ही कहानी है। standard programmers उन्हें लेते ही नहीं, वहां अपनी अलग handling चाहिए, और J4858B/J4859C पर आम circuit से मैं कोई सफलता की उम्मीद नहीं रखूंगा। अगर काम बस किसी दूसरे के switch में एक working module पाना है, तो HP को तड़पाने से सस्ता है कि honest memory वाला कोई module लो और उसमें vendor image पूरा भर दो: 256 byte के dump में से पहले 128 ही मायने रखते हैं, बाकी manufacturer का reserve है।
कोई भी vendor ऐसी recoding को, ज़ाहिर है, support नहीं करता: recoded module के साथ support के पास जाने को कुछ बचता ही नहीं।
कुछ बातें साफ कर दो, वरना अंदाज़ा लगाना ही रह जाएगा। No Acknowledge device के address पर ही आता है या data के पहले byte के बाद? programmer के log में यह आमतौर पर दिख जाता है। और तुम्हारा programmer है क्या - कोई तैयार device या अपनी circuit वाली homemade चीज़? cage पर 3.3 V से क्या उम्मीद रखनी है, यह इसी पर depend करता है।
power देने पर व्यवहार भी दिलचस्प है: module लगाते ही रिजेक्शन वैसा ही है जैसा कुछ मिनट power में रहने के बाद? और चारों types एक जैसा व्यवहार करते हैं या Finisar और HP अलग हैं: HP की वजहें आमतौर पर अपनी होती हैं, उन्हें बाकी से पहले ही अलग कर लेना बेहतर है।
नतीजे बताता हूं। cage को छोड़कर सीधे pin 4 और 7 पर I2C line से solder किया। Finisar चल गए: FTLX8571D3BCV-IT लिखा गया और वापस read करके confirm भी हुआ, FTLX1471D3BCV-IT भी। GLC-LH-SM ने No Acknowledge देना बंद कर दिया और अब normal लिखा जाता है।
HP ने हार नहीं मानी। J4858B write को formally accept तो कर लेता है, पर edit के बाद switch module को reject कर देता है, J4859C भी वैसा ही करता है। तो मेरे लिए सवाल आधा ही बंद हुआ: Finisar और Cisco अब लिखता हूं, HP को बेहतर समय तक किनारे रख दिया।
HP में trap write protection से कहीं गहरा है, इसीलिए तुम्हारा नतीजा उम्मीद के मुताबिक ही है। J4858B पर byte 68-83, यानी serial number, edit करने पर byte 124-127 में checksum बदल जाता है, और उसके बाद module reject हो जाता है। यह MSA वाला CC_BASE और CC_EXT नहीं है, उन्हें निकालना कोई समस्या नहीं, बल्कि A0 के आखिरी चार bytes में एक अलग vendor checksum है। algorithm कितना भी कुरेदा गया, publicly कभी सुलझा ही नहीं।
J9150A भी उसी कहानी का हिस्सा है। और नए HP और Aruba modules में तो static checksum छोड़कर सीधे request-response scheme, HPIDv2, पर चले गए, और वहां programmer principle में ही बेकार है। तो "लिखा जाता है पर accept नहीं होता" - यही तो होना भी था।
चूंकि तुम्हारे पास एक module नहीं बल्कि पूरा park है, तो tool के बारे में बताता हूं। मैंने Huawei S5731 और S6730 के लिए, और HP 6120XG के लिए recoding हेतु Ubiquiti का UACC-SFP-WIZARD अपना लिया - एक सस्ते programmer के तौर पर वो काफी ज़िंदा है। बस खुद Ubiquiti के modules के लिए passwords की lists घूमती रहती हैं, 0x00001011, SFPX, QSFP जैसी entries, और उनके बिना कुछ modules write के लिए खुलते ही नहीं। images में से मेरे पास FTLX8571D3BCV और FTLX8574D3BCV चलन में हैं, कभी-कभार SNR-SFP+W73-3 और W37-3 भी।
ऊपर की generalization को थोड़ा ठीक कर दूं, ताकि कोई समय से पहले solder करने न बैठ जाए: हर SFP+ में memory microcontroller के पीछे छिपी नहीं होती। मेरे पास FTLX8574D3BCV और एक जोड़ी SNR-SFP+W73-3 cage में आम programmer से ही, बिना किसी soldering के, लिख गए। तो पहले अपने particular नमूने को check कर लेना चाहिए, तभी bypass में उतरना चाहिए।
वैसे write protect pin को ground करना भी कोई universal नुस्खा नहीं है: microcontroller वाले module पर इससे कुछ नहीं मिलता, वहां रिजेक्शन memory से नहीं, controller की firmware से आता है। यह operation सिर्फ वहीं मतलब रखता है जहां honest अलग EEPROM लगी हो, और इसे power off module पर ही करना चाहिए, वरना आसानी से module की जगह ईंट मिल सकती है।