أي checksums في الـ EEPROM يجب إعادة حسابها بعد تعديل اسم المورّد ورقم القطعة في صورة SFP
عمل على الطاولة: إعادة برمجة (re-coding) دفعة صغيرة من وحدات SFP+ لتحمل نص المورّد ورقم القطعة الذي يتوقعه جهاز العميل. التعديل نفسه بسيط في محرر hex، والكتابة تتم بنجاح، والقراءة بعد الكتابة تطابق بايت بايت ما كتبته - ومع ذلك الجهاز المضيف (host) لا يزال يرفض الوحدة.
- وحدات SFP+ عامة، تم تعديل صفحة A0 يدويًا
- برمجة (programmer) قائمة على CH341 مع الأداة المرفقة معها
- الحقول المعدَّلة: اسم المورّد ورقم قطعة المورّد، لا شيء آخر تم لمسه
- كتابة نسخة (dump) غير معدَّلة على نفس الوحدة تعمل بشكل جيد، لذا مسار الكتابة نفسه ليس المشكلة
ما قارنته بعد التعديل:
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إذن من الواضح أن بايتات المجموع (sum bytes) لم تتغير عندما تغيرت البيانات. قبل أن أذهب لكتابة أدواتي الخاصة لهذا الأمر: ما هي نطاقات البايتات التي يغطيها هذان المجموعان فعليًا، وهل هما مجموعان جمعيان (additive) بسيطان أم شيء على شكل CRC، وهل توجد أداة مصانة تعيد حسابهما حتى لا أقوم بالحساب يدويًا على كل وحدة؟
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
برمجتك تفعل ما تفعله أدوات CH341 عادةً، وهو لا شيء. فهي تكتب البايتات التي تعطيها إياها ولا تلمس حقول checksum إطلاقًا. برمجات المورّدين تعيد الحساب عند الكتابة، ولهذا فإن من يستخدم تلك الأدوات فقط لا يواجهون هذه المشكلة أبدًا ويقتنعون أن الموضوع بأكمله وهمي.
هناك أمران يستحقان التحديد قبل أن تكتب أي أدوات. أولًا، ما الذي قرأ الصورة بعد الكتابة - نفس الأداة التي كتبتها، أم شيء مستقل؟ القارئ الذي يقدم لك نسخته المخبأة (cache) الخاصة سيُظهر بسعادة بايتًا لم يصل فعليًا إلى الشريحة أبدًا. ثانيًا، هل قمت بحساب مجموع البايتات من 0 إلى 62 في الصورة المعدَّلة بنفسك ومقارنته ببايت 63، أم أنك فقط تقارن بايت 63 مع النسخة الأصلية؟ عدم التغيير والصحة ليسا نفس الاختبار، وملاحظاتك تُظهر الأول فقط.
يستحق أيضًا ذكر اسم الجهاز المضيف الذي يرفضها. بعضها يقرأ حقول الهوية ولا يتحقق من شيء، وبعضها الآخر يتحقق بصرامة ويستبعد الوحدة فور اختلاف المجموع. نفس الصورة، حكم مختلف.
هناك اثنان منهما وهما مجموعان بسيطان من 8 بت (dumb 8-bit sums)، لا يوجد CRC في أي مكان.
اسم المورّد ورقم قطعة المورّد كلاهما يقعان في المنطقة الأساسية (base area)، لذا تعديلك أبطل CC_BASE بينما بقي CC_EXT صحيحًا بشكل شرعي. تعديلات الرقم التسلسلي وكود التاريخ تصيب النطاق الموسّع (extended range) بدلًا من ذلك، وعندها يصبح البايت 95 هو الذي يصبح قديمًا (stale). إعادة حساب أي منهما هي سطران فوق البافر: اجمع النطاق، طبّق mask بـ 0xFF، وخزّن النتيجة في بايت المجموع.
إذا كنت لا تفضل فعل ذلك يدويًا، هناك أدوات جاهزة. py-sfp-eeprom يبني ويتحقق من صور EEPROM من Python (
python3 -m sfp_eeprom)، وsfppiيعمل على Raspberry Pi، يتحقق من المجاميع ويعرض إصلاحها. أي منهما عادة أفضل من محرر hex مع حساب ذهني، لأن نمط الفشل صامت - الوحدة تُقرأ بالضبط كما كتبتها ويشتكي المضيف فقط.الحصول على مجموعي MSA بشكل صحيح ضروري، وحسب المنفذ الذي تدخل فيه، غير كافٍ.
Cisco هي المثال المعروف جيدًا: فحص الهوية ليس مجرد النصوص. توصل شخص ما منذ سنوات إلى أن القيمة التي تحملها وحدة مُكوَّدة بطريقة Cisco يمكن إعادة إنتاجها بلا شيء أكثر غرابة من
xxd -r -p | md5sum، بإدخال بايت كود المورّد ثم بايتات الاسم. في تلك النسخ (dumps) الكود والاسم مرتبطان ببعضهما - Finisar وراء 02، Methode وراء 0E. اجعلهما مختلفين وسويتش Catalyst 2960X سيرفض الوحدة مرة أخرى، سواء استخدمت أوامر فتح القفل (unlock commands) أم لا.هذا عادة ما يفسر لماذا تتوقف نسخة تم أخذها من وحدة تعمل عن العمل بمجرد أن يلصق أحدهم نص مورّد مختلف فيها. المجاميع سليمة، لكن الهوية لم تعد متسقة مع نفسها.
تصحيح بسيط لفكرة "أصلح المجموعين وانتهى الأمر": هذا صحيح بالنسبة لحقول MSA، وليس لكل فكرة كل مورّد عن الصورة الصالحة.
HP هي المثال المضاد القائم. عدّل الرقم التسلسلي في صورة J4858B، البايتات من 68 إلى 83، وستتغير أيضًا البايتات من 124 إلى 127 في A0 - وهو checksum خاص بالمورّد يقع بعد بايتات CC_BASE وCC_EXT الخاصة بـ MSA. نوقش هذا باستفاضة ولم ينشر أحد الخوارزمية أبدًا؛ أكد الناس أن البايتات مهمة وانتهى الموضوع عند ذلك. نفس القصة أُبلغ عنها حول J4859C وJ9150A. أجهزة HP وAruba اللاحقة انتقلت إلى نظام تحدي-استجابة (challenge response) يُسمى HPIDv2، وهو ما لا يمكنك تزويره في EEPROM على الإطلاق.
لذا قبل أن تستثمر في الأدوات، حدد ما الذي يتحقق منه المضيف الهدف: مجموعان جمعيان لمضيف عادي، هوية متسقة داخليًا بالنسبة لـ Catalyst، وفي بعض أجزاء HP حقل غير موثّق لن تستطيع إعادة إنتاجه.