Turris Omnia يرفض عصا MA5671A GPON مفتوحة القفل: eth2 لا يعمل أبدًا على Turris OS 5.0.3
أحاول استبدال طرفية مزود الخدمة في راكي المنزلي بعصا GPON مباشرة في الراوتر، بحيث تصل الألياف إلى صندوق واحد بدلاً من اثنين. العصا مُكتشفة، وهنا تنتهي الأخبار الجيدة.
- Turris Omnia على Turris OS 5.0.3، نواة قياسية
- عصا Huawei MA5671A GPON بفيرموير مفتوح القفل، مضبوطة على SGMII 1G
- كابل SC/APC pigtail من مقبس الحائط إلى العصا
- eth2 هو منفذ SFP
الوحدة مكتشفة لكن الواجهة لا تُفعَّل أبدًا:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bيبقى eth2 معطلاً بعد ذلك، لا حامل (carrier)، لا شيء في العدادات.
ما جربته حتى الآن:
- إعادة فلاش العصا إلى الفيرموير القياسي، مما يعطيني خطأ قراءة EEPROM بدلاً من ذلك
- إجبار المعدل بـ ethtool -s eth2 1000 autoneg off duplex full، وبعدها تستقر الواجهة عند 10 ميجابت نصف ازدواجية
- نقل نفس العصا إلى راوتر MikroTik، حيث تعمل فعلاً بمجرد ضبط سرعة المنفذ يدويًا
إذًا الوحدة نفسها حية وجانب الألياف سليم. ما الذي في العصا تعترض عليه النواة، وأي عصي GPON تعمل فعلاً على Omnia بدلاً من أن تُرفض؟
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
هذه مشكلة من جانب المضيف، وليست وحدة معطلة. EEPROM في عصي GPON المُعاد استخدامها هذه يعلن ترميزًا لن يعينه تعريف sfp الرئيسي (mainline)، لذا يرفض phylink تشغيل المنفذ، والسطر الذي لصقته هو التعريف يقول ذلك بالضبط. دليلك الخاص يشير لنفس الاتجاه: نفس العصا تعمل على MikroTik بمجرد ضبط سرعة المنفذ يدويًا، إذًا البصريات وجانب PON سليمان.
الشيء الوحيد الذي حرّك الأمر بالنسبة لي كان نواة حديثة بما يكفي لتحمل الاستثناءات (quirks) الخاصة بكل وحدة، وهو ما يعني على Omnia فرع اختبار HBD مع النواة 5.4. كن حذرًا فهذا فوز جزئي ويعتمد بشدة على العصا التي لديك. على تلك النواة:
إذًا إذا أردت أن يعمل Omnia الآن بدلاً من لاحقًا، فإن DFP-34G-2C2 هو ما سأضعه في القفص. اختبره على جهازك الخاص قبل الالتزام به، فالنتائج هنا تختلف بوضوح بين العصي وحتى بين إصدارات الفيرموير لنفس العصا.
شيئان يستحقان التحديد قبل أن يبدأ أحد بالتخمين. أولاً، من أي فرع جاء 5.0.3 هذا وماذا يبلغ uname عن النواة؟ استثناءات SFP الخاصة بكل وحدة التي تحتاجها عصي GPON المُعاد استخدامها هذه وصلت لاحقًا، لذا نواة مستقرة مشحونة ونواة اختبارية تتصرفان بشكل مختلف تمامًا مع نفس الوحدة بالضبط.
ثانيًا، هل الرقم التسلسلي لـ ONU مسجل من جانب المزود؟ عصا لا تُصرَّح لها أبدًا على OLT ستبقى تبدو ميتة، والكثير من المزودين يرفضون تسجيل ONU من طرف ثالث إطلاقًا.
وعند توصيلها، هل يتحول المنفذ أبدًا إلى inband/1000base-x، أم يتوقف السجل تمامًا عند رسالة الترميز تلك؟
فرع مستقر، نواة قياسية لـ 5.0.3، لا شيء مخصص فوقها. جانب المزود ليس المشكلة هنا، إنها نفس الألياف والعصا تحمل الرقم التسلسلي المسجل.
يتوقف السجل عند سطر الترميز، ولا يتحول المنفذ أبدًا إلى inband/1000base-x. ما أحصل عليه يعتمد على الفيرموير. مع الفيرموير المفتوح القفل:
بالإضافة إلى خطأ إرسال تُبلغ عنه الوحدة. مع الفيرموير القياسي لا يصل الأمر حتى إلى هذا الحد:
وكما قلت، إجبار المعدل لا يفعل شيئًا إطلاقًا: بعد ethtool -s eth2 1000 autoneg off duplex full تبقى الواجهة عند 10 ميجابت نصف ازدواجية.
نمط فشل آخر يجب استبعاده على نفس الراوتر، لأنه يبدو مشابهًا ولا علاقة له بالترميز. HALNy HL-GSFP على Turris OS HBS 6.2.4 تم اكتشافها، وحوّل المنفذ حتى إلى inband/1000base-x، ثم انقطع الرابط وبقي eth2 معطلاً.
السبب: تلك العصا هي حاسوب صغير بحد ذاتها. تقضي نحو دقيقة في تشغيل فيرموير خاص بها، وفقط بعد ذلك تجيب القفص بأي شيء منطقي. الإقلاع البارد يجعل الراوتر ينظر إلى القفص قبل تلك اللحظة بكثير، فيفشل الاكتشاف ويعود الصندوق بهدوء إلى مغناطيسية WAN النحاسية. إطالة تأخير الإقلاع أصلحت الأمر:
ستون ثانية بدلاً من الافتراضي ثلاث، وأكّد ذلك شخص آخر بنفس العصا. شيئان آخران ساعدا: افصل كابل WAN النحاسي وأعد التشغيل مرة أخرى، وسجّل الدخول إلى الوحدة نفسها لترى في أي حالة هي، عبر المنفذ التسلسلي بمعدل 38400 8N1 أو عبر SSH على 192.168.77.154 المنفذ 22666.