SFP image में vendor name और PN edit करने के बाद कौन से EEPROM checksums recalculate करने होंगे
Bench पर काम: SFP+ modules का एक छोटा batch re-code कर रहा हूं ताकि उनमें वही vendor string और part number आए जो customer की kit चाहती है। edit खुद hex editor में trivial है, write गुज़र जाता है, वापस पढ़ने पर वही byte for byte मिलता है जो मैंने लिखा - और host फिर भी module को बाहर फेंक देता है।
- generic SFP+ modules, A0 page हाथ से edit किया
- CH341 based programmer, साथ आए tool के साथ
- edit की गई fields: vendor name और vendor part number, और कुछ नहीं छुआ
- उसी module में एक बिना छेड़ा हुआ dump वापस लिखने पर ठीक काम करता है, तो write path खुद problem नहीं है
edit के बाद मैंने जो compare किया:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorतो payload बदलने पर sum bytes साफ तौर पर हिले ही नहीं। इसके लिए खुद tooling लिखने जाने से पहले: वो दोनों sums असल में किन byte ranges को cover करते हैं, क्या वो plain additive sums हैं या कुछ CRC जैसा, और क्या कोई maintained utility है जो इन्हें recalculate कर दे ताकि मुझे हर module पर हाथ से arithmetic न करनी पड़े?
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
आपका programmer वही कर रहा है जो CH341 based tools सामान्यतः करते हैं, यानी कुछ नहीं। ये वो bytes लिख देते हैं जो आप देते हो और checksum fields को कभी छूते नहीं। Vendor programmers write पर recalculate करते हैं, इसीलिए जो लोग सिर्फ वही इस्तेमाल करते हैं उन्हें यह कभी मिलता ही नहीं और उन्हें यकीन हो जाता है कि यह पूरा topic काल्पनिक है।
कोई भी tooling लिखने से पहले दो चीज़ें पक्की करने लायक हैं। पहली, write के बाद image वापस किसने पढ़ी - वही tool जिसने लिखी, या कुछ independent? एक reader जो अपना खुद का cache परोसता है वो खुशी-खुशी वो byte दिखा देगा जो chip में गया ही नहीं। दूसरी, क्या आपने edited image के byte 0 से 62 तक का sum खुद निकालकर byte 63 से compare किया, या आप सिर्फ byte 63 को original dump से compare कर रहे हो? unchanged और correct एक जैसा test नहीं है, और आपके notes सिर्फ पहला दिखाते हैं।
उस host का नाम लेना भी ज़रूरी है जो इसे reject करता है। कुछ identity fields पढ़ते हैं और कुछ verify नहीं करते, कुछ सख्ती से validate करते हैं और sum गलत होते ही module गिरा देते हैं। image वही, फैसला अलग।
ये दो हैं और dumb 8-bit sums हैं, कहीं भी कोई CRC शामिल नहीं।
Vendor name और vendor PN दोनों base area में रहते हैं, तो आपके edit ने CC_BASE invalidate कर दिया जबकि CC_EXT वैध रूप से सही बना रहा। Serial number और date code के edits इसके बजाय extended range को छूते हैं, और तब byte 95 stale हो जाता है। इनमें से किसी को भी दोबारा compute करना buffer पर बस दो lines का काम है: range का sum लो, 0xFF से mask करो, sum byte में store कर दो।
अगर हाथ से नहीं करना, तो tooling मौजूद है। py-sfp-eeprom Python से EEPROM images बनाता और validate करता है (
python3 -m sfp_eeprom), औरsfppiRaspberry Pi पर चलता है, sums check करता है और उन्हें ठीक करने का offer भी देता है। hex editor और mental arithmetic से दोनों में से कोई भी बेहतर आदत है, क्योंकि failure mode चुपचाप होता है - module ठीक वैसे ही वापस पढ़ता है जैसे आपने लिखा और सिर्फ host ही शिकायत करता है।दोनों MSA sums को सही करना ज़रूरी है, और आप किस port में plug कर रहे हो उस पर निर्भर करते हुए, काफी नहीं भी।
Cisco इसका जाना-पहचाना उदाहरण है: identity check सिर्फ strings का नहीं है। सालों पहले किसी ने पता लगाया था कि एक Cisco coded module जो value carry करता है उसे
xxd -r -p | md5sumजितनी ही सामान्य चीज़ से reproduce किया जा सकता है, जिसमें vendor code byte और फिर name bytes दिए जाएं। उन dumps में code और name एक-दूसरे से बंधे होते हैं - Finisar 02 के पीछे बैठता है, Methode 0E के पीछे। दोनों असहमत हो जाएं तो Catalyst 2960X module को फिर से उगल देता है, unlock commands हों या न हों।यही आमतौर पर वजह है कि एक working module से copy किया dump किसी के अलग vendor string paste करते ही काम करना बंद कर देता है। sums ठीक हैं, बस identity अब खुद से consistent नहीं रही।
"दो sums ठीक करो और काम खत्म" वाली framing में एक छोटी सी correction: यह MSA fields के लिए सही है, हर vendor के valid image के विचार के लिए नहीं।
HP इसका पक्का counterexample है। J4858B image में serial number, bytes 68 से 83, edit करो तो A0 के bytes 124 से 127 भी बदल जाते हैं - एक vendor checksum जो MSA के CC_BASE और CC_EXT bytes से आगे बैठा है। उस पर लंबे समय तक चर्चा हुई और algorithm किसी ने कभी publish नहीं किया; लोगों ने बस इतना confirm किया कि bytes मायने रखते हैं और thread वहीं खत्म हो गई। J4859C और J9150A के आसपास भी वही कहानी report हुई। बाद में HP और Aruba gear एक challenge response scheme (HPIDv2) पर चले गए, जिसे EEPROM में बिल्कुल भी forge नहीं किया जा सकता।
तो tooling में लगाने से पहले, यह पता करो कि target host validate क्या करता है: plain host के लिए दो additive sums, Catalyst के लिए एक internally consistent identity, और कुछ HP parts पर एक undocumented field जिसे आप reproduce नहीं कर पाओगे।