المبرمج (programmer) يقرأ وحدة SFP+ من طراز FTLX8571D3BCV-IT، لكنه يرد بـ No Acknowledge عند الكتابة
أحتفظ بمخزون صغير للتبادل من الوحدات: العُقد موزعة في أنحاء المدينة، وتقريبًا لكل محول لدى شخص آخر يجب إعادة ترميز SFP. مع الوحدات بسرعة غيغابت واحد الطريقة مجربة منذ زمن، لكن مع وحدة بسرعة عشرة تعثرت.
ما لديّ على الطاولة:
- مبرمج (programmer) بمقبس SFP/SFP+، بجهد تغذية 3.3 فولت
- Finisar FTLX8571D3BCV-IT وFTLX1471D3BCV-IT، وكلاهما يُقرأ
- Cisco GLC-LH-SM من مخزون قديم
- HP J4858B وJ4859C
القراءة تتم بثبات وبشكل متكرر، كلا البنكين بالكامل. الكتابة لا تنجح في أي حالة:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledgeما تحققت منه بالفعل:
- نفس العمليات على وحدات SFP عادية بسرعة غيغابت واحد بنفس المبرمج تنجح، أي أن الدارة والتغذية سليمتان؛
- أخذت نسخة ثانية من FTLX8571D3BCV-IT، والسلوك متطابق تمامًا؛
- على GLC-LH-SM تصل No Acknowledge فورًا، حتى قبل محاولة لمس حقول المورّد.
يبدو إذن أن الأمر لا يتعلق بنسخة معينة. هل هذه حماية كتابة على مستوى العتاد داخل الوحدة نفسها، أم أن ذاكرة SFP+ لم تعد EEPROM عارية ولا يمكن الوصول إليها بكتابة I2C عادية؟ ويهمني بشكل منفصل موضوع HP J4858B/J4859C: هل يكتبها أحد بمبرمج عادي، أم أن هذا طريق مسدود مسبقًا؟
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
هنا اختلطت آليتان مختلفتان، وتُعالجان بطرق مختلفة.
الأولى - ذاكرة EEPROM عادية بحماية كتابة على مستوى العتاد. لدى شريحة الذاكرة طرف write protect، وطالما هو مرفوع، فإن القراءة تعمل بينما تفشل الكتابة. الطريقة التي نصح بها من تعامل مع هذا عن قرب هي توصيل هذا الطرف بالأرضي أثناء عملية الكتابة. في جزء من الوحدات بسرعة غيغابت واحد هذا كافٍ.
الثانية - وهي ما واجهته مع وحدة العشرة غيغابت. في SFP+ غالبًا لا تكون البيانات في EEPROM منفصلة، بل خلف متحكم دقيق (microcontroller) داخل الوحدة: هو من يعرض A0 وA2 للقراءة ولا يقبل الكتابة إلا بتسلسل أوامر خاص به. المبرمج القياسي لا يعرف هذا التسلسل ويحصل على No Acknowledge على أي محاولة، بغض النظر عن الحقل المستهدف. لا شيء هناك للتأريض.
ما يساعد فعليًا على تجاوز المقبس: لحام أسلاك مباشرة إلى الطرفين 4 و7 من الوحدة، أي على خطوط I2C، متجاوزًا موصل المبرمج. حسب التجارب، بعد ذلك تُكتب بعض الوحدات التي كانت صامتة داخل المقبس. الطريقة خشنة، وتحتاج يدًا ثابتة، وتبقى الوحدة بعدها على مسؤوليتك.
HP قصة منفصلة. المبرمجات القياسية لا تتعامل معها، فهناك حاجة إلى معالجة خاصة، وعلى J4858B/J4859C بالدارة العادية لا أتوقع نجاحًا. إذا كان الهدف هو مجرد الحصول على وحدة تعمل في محول شخص آخر، فمن الأرخص عدم إتعاب نفسك مع HP، بل أخذ وحدة بذاكرة صريحة ونسخ صورة المورّد بكاملها فيها: من أصل 256 بايت في المفرغة (dump)، أول 128 بايت فقط ذات دلالة، والباقي احتياطي من المصنّع.
ولا يدعم أي مورّد بالطبع إعادة الترميز هذه: بوحدة مُعاد برمجتها لا يوجد ما تذهب به إلى الدعم.
وضّح لي بضعة أمور، وإلا سيكون الأمر تخمينًا. هل تصل No Acknowledge عند عنوان الجهاز نفسه أم بعد أول بايت بيانات؟ عادة يظهر هذا في سجل المبرمج. وما هو نوع المبرمج لديك - جهاز جاهز أم مصنوع يدويًا بدارة خاصة؟ على هذا يعتمد ما يمكن توقعه من 3.3 فولت على المقبس أصلًا.
ومن المهم أيضًا معرفة السلوك عند تشغيل التغذية: هل الرفض نفسه فورًا بعد تركيب الوحدة وبعد أن تبقى تحت التغذية بضع دقائق؟ وهل تتصرف الأنواع الأربعة كلها بنفس الطريقة أم أن Finisar وHP تختلفان: عادة ما يكون لدى HP أسباب رفض خاصة بها، ومن الأفضل فصلها عن الباقي منذ البداية.
أقدّم تقريرًا بالنتائج. لحمت على خطوط I2C مباشرة إلى الطرفين 4 و7، متجاوزًا المقبس. Finisar نجحت: FTLX8571D3BCV-IT كُتبت وتأكدت بقراءة عكسية، وكذلك FTLX1471D3BCV-IT. GLC-LH-SM توقفت عن إعطاء No Acknowledge وتُكتب بشكل طبيعي.
HP لم تستسلم. J4858B تقبل الكتابة شكليًا، لكن بعد التعديل يرفض المحول الوحدة، وJ4859C يتصرف بنفس الطريقة. إذن بالنسبة لي السؤال مُغلق نصفيًا: Finisar وCisco أكتبهما الآن، وHP أجّلتها إلى وقت أفضل.
الفخ مع HP أعمق من مجرد حماية كتابة، لذا فإن نتيجتك متوقعة. في J4858B عند تعديل البايتات 68-83، أي الرقم التسلسلي، يتغير مجموع التحقق (checksum) في البايتات 124-127، وتُرفض الوحدة بعد ذلك. هذا ليس CC_BASE وCC_EXT الخاصين بمعيار MSA، فحسابهما ليس مشكلة، بل هو مجموع تحقق خاص بالمورّد في آخر أربعة بايتات من A0. لم يُكشف الخوارزم علنًا مهما حاول الناس فك تشفيره.
J9150A من نفس النوع. وفي وحدات HP وAruba الأحدث تخلّوا كليًا عن مجموع التحقق الثابت لصالح مخطط سؤال-جواب، يُسمى HPIDv2، وهناك المبرمج عديم الفائدة من حيث المبدأ. إذن فـ«تُكتب لكن لا تُقبل» هي بالضبط النتيجة المتوقعة.
بما أن لديك أسطولًا وليس وحدة واحدة، سأتحدث عن الأداة. أنا اعتمدت لإعادة الترميز الخاصة بـ Huawei S5731 وS6730 ولـ HP 6120XG جهاز UACC-SFP-WIZARD من Ubiquiti - كمبرمج رخيص فهو جيد جدًا. فقط فيما يخص وحدات Ubiquiti نفسها تتداول قوائم كلمات مرور، سجلات مثل 0x00001011، SFPX، QSFP، وبدونها لا تُفتح بعض الوحدات للكتابة. من الصور التي أستخدمها FTLX8571D3BCV وFTLX8574D3BCV، وأحيانًا SNR-SFP+W73-3 وW37-3.
أصحح التعميم أعلاه، حتى لا يندفع أحد نحو مكواة اللحام قبل الأوان: ليست كل SFP+ مخفية الذاكرة خلف متحكم دقيق. لديّ FTLX8574D3BCV وزوج من SNR-SFP+W73-3 كُتبت بمبرمج عادي داخل المقبس، دون أي لحام. لذا يستحق الأمر أولًا فحص النسخة المحددة قبل اللجوء إلى الطرق البديلة.
وتأريض طرف write protect، بالمناسبة، ليس وصفة عامة أيضًا: على الوحدة ذات المتحكم الدقيق لا يفيد بشيء، فالرفض هناك يأتي من برنامج المتحكم وليس من الذاكرة. هذه العملية لها معنى فقط حيث توجد EEPROM منفصلة صريحة، ويجب تنفيذها والوحدة منزوعة التغذية، وإلا فمن السهل الحصول على قطعة معطلة تمامًا بدلًا من وحدة.