IC-prog يُعيد 256 بايت من نسخة SFP، لكن النصف الثاني نسخة من الأول، صفحة A2 لا تُقرأ (HP 2530-24G)
أدير شبكة مشغّل صغير، وأُعيد تحميل برنامج الوحدات الرخيصة لتوافق HP بانتظام. المهمة معتادة: أنسخ إلى وحدات WDM صينية بسرعة 1.25G صورة وحدة رسمية، حتى يقبلها المحوّل دون اعتراض. المصدر J4859C، والجهاز المستهدف HP 2530-24G J9776A.
ما هو على الطاولة:
- محوّل HP 2530-24G J9776A
- وحدات OptiCin وFiberstore، 1.25G WDM
- مبرمج mini-USB من نوع NAG
- IC-prog تحت Windows، أقرأ وأكتب عبره
النسخة تُؤخذ بحجم 256 بايت، لكن النصف الثاني يطابق الأول بايتاً ببايت:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedما جربته بالفعل:
- أعدت تركيب الوحدة، نظّفت التلامسات في المقبس، غيّرت المزلاج
- شغّلت ثلاث وحدات من دفعات مختلفة، نفس الصورة
- غيّرت منفذ USB والكابل والجهاز، لم يتغيّر شيء
أحتاج الصفحة الثانية، حيث DDM والبايتات الخدمية، وببساطة لا أراها. هل هذا قيد في IC-prog، أم لوحة مبرمج معيبة، أم أن الوحدات نفسها تتصرف هكذا؟
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 7
هنا خللان مستقلان، وكلاهما ليس في الوحدات.
الأول هو IC-prog نفسه. لديه نموذج عنونة خطي، لا يعرف تبديل الصفحات ولا يمكنه الوصول إلى A2 من حيث المبدأ. ما تراه في النصف الثاني من النسخة هو A0 نفسها، مقروءة مرة ثانية. لن يُظهر خطأً، لأنه من وجهة نظره كل شيء صحيح.
الثاني هو اللوحة. على هذا المبرمج من نوع mini-USB، VccR (الدبوس 15) موصول بـ+5 فولت، رغم أنه وفق SFF-8431 يجب أن يبقى حراً، بالإضافة إلى أن توصيل الطاقة والأرضي موزّع بحيث لا تدخل بعض الوحدات إلى وضع عادي. من هنا تأتي
No Acknowledge received- ليس على الجميع، بل على من لا يعجبه هذا التوصيل.ما يعمل بشكل طبيعي:
i2cdump -y 3 0x50وi2cdump -y 3 0x51، ويوجد سكربت Python مفتوح يقرأ ويكتب كلا الصفحتين.المعيار بسيط: بمجرد أن يبدأ 0x51 بالرد، يصبح ما يلي عملاً عادياً مع ذاكرة الوحدة، لا صراعاً مع الأداة.
افصل بين البرنامج والعتاد، وإلا ستُخمّن حتى المساء. خذ أي Linux وانظر هل تجيب الوحدة على العنوان الثاني أصلاً:
ضع رقم الناقل الخاص بك. إن قُرئ 0x50 وصمت 0x51 - فالسؤال لم يعد عن الأداة التي تنظر بها إلى النسخة، بل هل يصل إلى الوحدة توصيل طاقة طبيعي. وقل ماذا يُعيد نفس المبرمج مع J4859C الأصلي الذي تأكدت من صلاحيته: إن لم تُفتح الصفحة الثانية له أيضاً، فالوحدات الرخيصة ليست السبب هنا، ويجب الحفر في اقتران البرنامج مع اللوحة.
شغّلت المصدر أولاً: J4859C الحي في نفس المقبس ونفس IC-prog يعطي بالضبط نفس الصورة - 256 بايت، النصف الثاني يكرر الأول. إذن الأمر ليس بسبب الوحدات الرخيصة. تحققت أيضاً تحت Linux عبر المحوّل:
الأداة الأصلية على نفس الوحدة تُظهر
No Acknowledge received، وIC-prog يعرض بصمت نسخة من الصفحة الأولى ويتظاهر بأن كل شيء بخير. الوحدات المستهدفة هي OptiCin، والصورة آخذها بالضبط من هذا J4859C.بخصوص الكتابة نفسها أضيف: في دمب بحجم 256 بايت، المهم هو أول 128 بايت، وما بعدها منطقة المصنّع التي عادة يمكن عدم لمسها إطلاقًا. لأجهزة HP نكتب صور J4858C وJ4859C، ولـ WDM كفت صورة LX عادية مرتين: المفتاح كان يقبل الوحدة ولا ينظر إلى الطول الموجي.
لكن ليس كل شيء قابلًا للكتابة. على 3Com 3CSFP91 و3CSFP92، وكذلك على وحدات Allied Telesis ذات العلامة التجارية، لم تنجح الكتابة إطلاقًا: القراءة تعمل بشكل طبيعي، لكن الكتابة لا تُطبَّق - WP مقفول (write-protect). لذلك إذا كانت صفحة A2 تُقرأ بعد تغيير المبرمج، لكن الكتابة تختفي بصمت دون أثر، فابحث عن السبب في غير البرمجيات.
أتحفظ بخصوص 'ما يلي عمل عادي مع الذاكرة'. ليس عادياً في كل مكان. بعض الوحدات ليست EEPROM إطلاقاً: في Medick SFP-10G-BX يوجد متحكم دقيق C8051F392 يُحاكي A0/A2 ويستطيع طلب كلمة مرور أو الرد على تحدٍّ (challenge). من الخارج يبدو كذاكرة عادية بالضبط حتى لحظة الكتابة. أصعب حالة واجهتها هي EEPROM تفاعلية عند HP/Aruba بمفاتيح، وهناك لا شيء يمكن فعله دون أداة جاهزة.
وإن كنت تجمع محوّلاً بنفسك، لا تخلط الأرجل: TX_Disable هو الدبوس 3، Mod_Abs هو الدبوس 6، VeeR هو الدبوس 9. نصف الوحدات 'غير القابلة للقراءة' عند معارفي تبيّن أنها بسبب مقبس مُجمّع بشكل خاطئ وليس حماية من المورّد.
من بين ما يُستخدم حالياً: SNR SFP Writer، وسلسلة SFPTotal Plus وأدوات مصنوعة يدوياً على CH341 - عادة هي مجرد لوحة بمقابس لـSFP وXFP وGBIC وQSFP، أحياناً في هيكل مطبوع. لا يوجد برنامج شامل، لكل مورّد أداته الخاصة، والصور تُسحب من قواعد بيانات البرامج الثابتة ومن المنتديات المتخصصة.
أمران يستحقان أكثر من ثمن العتاد. الأول: لدى كثير من الوحدات كلمة مرور من 4 بايتات، معظمها نُشر منذ زمن، لكن إن أخطأت ستحصل على قطعة معطلة من وحدة ليست رخيصة. الثاني: قبل الدخول إلى الذاكرة، تأكد من أن الوحدة حية أصلاً. درجة الحرارة، الجهد، تيار الانحياز، وTX/RX من A0h/A2h،
show interfaces diagnostics opticsعلى Junos أوdisplay interface transceiverعلى Huawei، ثم تنظيف المزاليج والتلامسات والعدسات، ثم الاستبدال بواحدة تعمل بالتأكيد. جزء من الوحدات 'الميتة' يعود للحياة بعد ذلك دون أي إعادة برمجة، والحمل تفحصه لاحقاً عبر iperf3.أُبلغ بالنتيجة النهائية. جمّعت لوحة على CH341، تحت Linux ردّ 0x51 فوراً، الصفحة الثانية تُقرأ كاملة، دون أي تكرار لأول 128 بايت. نسخت صورة J4859C إلى OptiCin، قبل HP 2530-24G J9776A الوحدة بصمت، DDM يُظهر قيماً معقولة، ويوم كامل تحت حمل عمل دون أخطاء.
حذفت IC-prog حتى لا أُغرى به مجدداً. 3Com 3CSFP91 الذي كان مُلقى بجانبي فعلاً لا يُكتب: يُقرأ، لكن الكتابة لا تُطبَّق، إذن كل شيء يتطابق مع WP. شكراً، السؤال مُغلق.