ما الذي يحسبه Catalyst 2960X في نسخة SFP: كود المورّد، الاسم وMD5، ولماذا لا تمر نسخة النسخة
أصون شبكة مزود خدمة، ومجموعة الوحدات مختلطة، لذا يتكرر تجهيز الوحدات لسويتشات محددة. أريد أخيرًا أن أفهم آلية الفحص بدلًا من تجربة نسخ عشوائية.
ما أعمل به:
- Cisco Catalyst 2960X-24PS-L، الأكثر تشددًا في المجموعة
- QTECH QSW-3750-28TX-AC وَD-Link DGS-3420، عليهما نفس الوحدات تعمل دون مشاكل
- وحدات SNR-SFP+SR وَSFP-10G-BX
في نسخة الوحدة التي تُقبل على Catalyst، أرى في البداية بايت كود المورّد يليه الاسم بترميز ASCII:
0E 43 49 53 43 4F ...ما جربته: أخذت نسخة من وحدة تعمل بلينك على C2960X-24PS-L، وأعدت كتابة اسم المورّد فقط من تلك النسخة في وحدة أخرى. على QTECH وَD-Link يعمل كل شيء بعد ذلك بلينك، لكن Catalyst لا يقبل تلك الوحدة، رغم أن البايتات المُعدَّلة تطابق المصدر (donor) واحدًا لواحد.
من هنا سؤالي حول بنية الفحص. ما الذي تحسبه Cisco بالضبط وعلى أي بايتات، وأين توجد النتيجة في الوحدة ولماذا لا يكفي اسم المورّد المُعاد كتابته من نسخة تعمل؟ ما يهمني هو المنطق، والباقي سأتدبره بنفسي.
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
الآلية هناك بسيطة وتم تحليلها منذ زمن. لا يُفحص حقل منفرد، بل ثنائي: بايت كود المورّد بالإضافة إلى بايتات اسم المورّد. من هذا التسلسل يُؤخذ MD5، والنتيجة موجودة في الوحدة نفسها، والسويتش يحسب نفس الشيء ويقارن.
يمكن إعادة إنتاجه بأدوات عادية، لا شيء خاص مطلوب:
تضع الكود واسم المورّد الخاصين بك وتحصل على القيمة التي يجب أن تكون موجودة في الوحدة. من الأكواد التي تظهر فعليًا في النسخ: 02 - Finisar، 0E - Methode، 11 يظهر بانتظام لكن لم يُعرف صاحبه أبدًا. إذا كان ثنائي الكود-الاسم متسقًا والهاش يطابقه، تمر الوحدة على C2960X-24PS-L.
بخصوص التعليق السابق: أرِنا ما هو موجود فعليًا في وحدتك المستقبِلة. أي بايت كود مورّد بقي هناك وأي اسم موضوع بجانبه؟ حسب الوصف، نقلت الاسم لكن تركت الكود أو الهاش نفسه من الوحدة الأصلية، وعندها ينفصل الثنائي ويرفضه Catalyst بشكل مشروع تمامًا. تحقق من الأشياء الثلاثة معًا، وليس فقط الحقل الذي يظهر في مخرجات السويتش.
تحققت، كل شيء يتطابق مع نسختك. في المصدر (donor) 0E ثم CISCO، وفي المستقبِلة أعدت كتابة الاسم فعلًا، لكن كود المورّد بقي أصليًا، والهاش أيضًا قديم. شغّلت كلا المجموعتين عبر xxd -r -p وَmd5sum: قيمة المصدر تطابق ما هو موجود في الوحدة، أما التي جمعتها يدويًا فلا.
إذن يجب نقل الثنائي كاملًا، وليس حقلًا واحدًا في كل مرة. الآن على الأقل فهمت أين أنظر وماذا أقارن قبل تركيب الوحدة في المنفذ.
نتيجة مهمة يُنسى ذكرها باستمرار: إذا لم يكن كود المورّد والاسم متسقين، لن تمر الوحدة على Catalyst حتى عندما تكون الوحدات غير المدعومة مسموحة على السويتش. لهذا السبب بالضبط تعمل النسخ المأخوذة من آخرين أحيانًا وأحيانًا لا - عُدِّلت جزئيًا، والفحص ينظر إلى الثنائي.
من هنا استنتاج عملي حول الحجم: في نسخة الـ256 بايت، أول 128 بايت مهمة، وبعدها تأتي منطقة المصنّع. لا داعي لسحب الصورة بأكملها، لكن يجب نقل النصف الأول بشكل متسق، بما في ذلك الحقول التي لا تُرى بالعين في مخرجات السويتش.
بالمناسبة، النسخة لا تحل كل شيء. في Medick SFP-10G-BX لا توجد ذاكرة بل متحكم دقيق C8051F392: يحاكي A0 وَA2 ويمكنه بسهولة الاحتفاظ بكلمة مرور أو طلب خاص بالمورّد. هناك حتى لو قارنت الثنائي بايتًا بايت - لن يُقبل من الخارج ببساطة. من الأدوات الحية التي أستخدمها SNR SFP Writer وَSFPTotal Plus، ولدى زملائي أيضًا أدوات مصنوعة يدويًا على CH341.
تصحيح بسيط حتى لا يختلط الأمر على من يصل إلى هنا لاحقًا. هذا الـMD5 لا علاقة له بمجاميع MSA: CC_BASE وَCC_EXT من SFF-8472 تُحسب بجمع بسيط للبايتات ويُعاد حسابها بسهولة تامة. الفحص الخاص بالمورّد يعمل فوقها وبقواعده الخاصة، ويرفض الوحدة تمامًا في اللحظة التي تكون فيها مجاميع MSA سليمة - من هنا الشعور بأن النسخة صحيحة والوحدة مع ذلك غير مقبولة.
Cisco هنا، بالمناسبة، ليست أسوأ حالة على الإطلاق: الآلية على الأقل مفهومة وقابلة لإعادة الإنتاج. الأصعب هي HP وَAruba، حيث تتصرف الذاكرة بشكل تفاعلي وتتطلب مفاتيح - هناك لن تكفيك النسخ بعد الآن.