موديول ODI DFP-34X-2C2 في جهاز Turris Omnia يعمل فقط بوضع 1000base-x، وethtool يرفض ضبط السرعة 2500
استبدلت ONU الخاص بمزوّد الإنترنت بعصا GPON من طراز ODI DFP-34X-2C2 في جهاز Turris Omnia الخاص بي، بحيث تنتهي الألياف الضوئية داخل الراوتر بدلاً من جهاز آخر على الرف. هذا الجزء نجح: الخط مسجَّل، والبيانات تتدفق، ولا شكاوى. المشكلة في السرعة. لا تتجاوز أبداً 1Gbps، وسرعة 2.5G كانت السبب الكامل وراء شرائي لهذه العصا.
- Turris Omnia، نظام TurrisOS 6.0.4
- عصا GPON طراز ODI DFP-34X-2C2 في منفذ SFP، eth2
- منفذ WAN النحاسي غير موصول، والمنفذ (cage) هو المتحكم في الواجهة
ما تقوله النواة (kernel) بعد الإقلاع، وما يحدث عندما أحاول فرض السرعة:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentأمر ethtool eth2 مع كون الوصلة up يُظهر الموديول كـ 1000baseX/Full ولا شيء أعلى من ذلك، والرفض أعلاه هو ethtool يخبرني أن السرعة 2500 لا يمكن الإعلان عنها (advertise).
ما جُرِّب حتى الآن:
- الدخول عبر telnet إلى العصا وضبط السرعة من واجهتها السطرية (shell) الخاصة؛ يقبل الأمر ثم يعود إلى 1Gbps
- إعادة التشغيل مع توصيل منفذ WAN النحاسي وبدونه
- بحثت في dmesg عن أي إشارة إلى عرض 2.5G على شريحة MAC، ولا يوجد شيء
هل هذا الراوتر هو من يحدّ سرعة المنفذ، أم الموديول نفسه؟ وهل هناك أي شيء من جانب المضيف (host) يجعل eth2 يعمل بوضع 2500base-x مع هذه العصا؟
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 5
السقف هنا هو الموديول نفسه، وليس جهاز Omnia.
ما يتفاوض عليه المضيف هو ما تعلن ذاكرة EEPROM الخاصة بالموديول أنه قادر عليه، لأن تلك الشريحة في لحظة الفحص (probe) هي الشيء الوحيد الذي يعتمد عليه المنفذ. على هذه العصا، هي مُبرمَجة على 1000Mbps. لذا يُهيَّأ المنفذ كـ inband/1000base-x، ولا يوجد وضع 2500base-x ليعرضه phylink، ويرفض ethtool السرعة 2500 لأنه لا يوجد شيء للإعلان عنه بها. لا يوجد أي إعداد من جانب المضيف يتجاوز ذلك: ethtool يمكنه فقط طلب الأوضاع التي أُخبر المنفذ بوجودها. الواجهة السطرية داخل العصا تُهيّئ جانب PON من الموديول، وليس ما يعلنه المنفذ باتجاه شريحة MAC، وهذا بالضبط سبب تلاشي تغييرك عبر telnet وعودتك إلى 1Gbps.
يبقى أمامك خياران حقيقيان: إعادة برمجة الموديول (re-coding) ليعلن عن 2.5G، أو استبداله بموديول يفعل ذلك أصلاً. إذا اخترت طريق إعادة البرمجة، احتفظ بموديول احتياطي جاهز. أنت تعيد كتابة صفحة الهوية التي يثق بها المضيف، وبايت خاطئ واحد هناك قد يجعل المنفذ يتوقف عن التعرّف على الموديول تماماً. احرص أيضاً على التمييز بين السرعتين في ذهنك: ما يوفّره جانب PON وما يتفاوض عليه رابط SFP-إلى-MAC رقمان منفصلان، لذا احسب ما ستكسبه فعلياً قبل إنفاق المال على هذا.
قبل إلقاء اللوم على العصا، تحقق من شجرة الأجهزة (device tree) التي يقلع بها الجهاز. منفذ SFP في Omnia ليس واجهة إضافية: فهو ونصف WAN النحاسي واجهتان أماميتان لنفس eth2 بالضبط، ويكون واحد منهما فقط موصولاً فعلياً بشريحة MAC في أي وقت. أيّهما يُحدَّد بحسب ملف dtb الذي تحمّله النواة عند الإقلاع. لذا انظر إلى ما يشير إليه /boot/dtb: إذا لم يكن armada-385-turris-omnia-sfp.dtb، فأنت تنظر إلى الجانب النحاسي والأرقام لا تعني شيئاً.
كما انشر المخرجات الكاملة لـ dmesg | grep -i sfp، وليس فقط سطر mvneta. ما تقرأه النواة من الموديول في لحظة الفحص (probe) هو الجزء المثير للاهتمام هنا، وعادة ما يحسم السؤال في سطر واحد.
ملف dtb هو بالفعل الخاص بـ SFP، فقد أنشأت رابطاً رمزياً (symlink) إلى armada-385-turris-omnia-sfp.dtb عندما ركّبت العصا لأول مرة، وإلا لما عمل أي شيء إطلاقاً. المنفذ (cage) هو المتحكم في eth2 وWAN النحاسي يبقى غير موصول.
أمر dmesg | grep -i sfp يُظهر التعرّف على الموديول ثم نفس السطر الذي نشرته، eth2 switched to inband/1000base-x link mode. لا شيء عن 2500 في أي مكان. أمر ethtool eth2 يُبلغ عن 1000baseX/Full بينما الوصلة up وتمرّر البيانات، وأمر ethtool -s eth2 speed 2500 لا يزال يعيد Invalid argument، لذا لن يعلن عن 2500 إطلاقاً. ضبط السرعة عبر telnet داخل العصا يتصرف بنفس الطريقة كما سابقاً، يقبله ثم يعود إلى 1Gbps.
قصة مشابهة من نفس اللوحة، في حال وصل أحد إلى هنا بعصا لا تعمل إطلاقاً بدلاً من عصا عالقة عند 1G. عصا HALNy HL-GSFP في جهاز Omnia على نظام Turris OS HBS 6.2.4: تعرّفت النواة عليها، بل تحوّل المنفذ إلى inband/1000base-x، ثم سقطت الوصلة ولم يعمل eth2 أبداً.
هذه المشكلة ليست في EEPROM. هناك نظام تشغيل صغير كامل يعيش داخل تلك العصا، ويحتاج إلى دقيقة تقريباً لنفسه قبل أن يكون في أي حالة تمكّنه من الرد على المضيف. عند بدء تشغيل بارد، يكون الراوتر قد فحص المنفذ واستسلم قبل تلك اللحظة بوقت طويل، فيعود المنفذ إلى الدائرة المغناطيسية النحاسية. إطالة تأخير U-Boot أصلح المشكلة هنا:
القيمة الافتراضية هي 3 ثوانٍ؛ عند 60 تكون العصا قد أنهت الإقلاع بحلول الوقت الذي تصل فيه النواة إلى فحص المنفذ. فصل WAN النحاسي وإعادة التشغيل مرة ثانية ساعد أيضاً في الاكتشاف. وإذا احتجت يوماً للنظر داخل عصا، فإعدادات المنفذ التسلسلي (serial) عليها هي 38400 8N1.
أتفق مع التشخيص، مع تحفظ واحد لمن يصل إلى هنا بعرض مشابه. ليست كل حالة "لا يعمل بسرعة 2.5G" على هذه اللوحة سببها الموديول. كانت هناك نسخة snapshot من OpenWrt تم فيها نقل (backport) شيفرة phylink validate العامة، وقد كسرت منفذ Omnia تماماً: كان ethtool لا يزال يعلن عن 2500baseX/Full لكنه يُبلغ Link detected: no. التراجع عن ذلك النقل أعاد المنفذ إلى ما كان عليه، حيث يقرأ ethtool Link detected: yes، 2500Mb/s full duplex، وحلّت طلبية سحب (pull request) لاحقة المشكلة في المصدر الأساسي (upstream).
العلامة الفارقة هي في ما يسرده ethtool على أنه مدعوم ومُعلَن عنه (supported وadvertised). إذا كان 2500baseX/Full موجوداً هناك وترفض الوصلة ببساطة أن تعمل، فانظر إلى النواة وphylink بعد آخر ترقية للصورة (image) لديك، وليس إلى الموديول البصري. أما إذا كان المنفذ، كما هنا، لا يعرف سوى 1000baseX لأن هذا ما أعلنه الموديول عن نفسه، فلن يستحضر أي برنامج على جانب المضيف هذا الوضع من العدم. هذا هو بايت معدل البت الاسمي (nominal bit rate) في EEPROM يفعل بالضبط ما يقوله معيار SFF-8472.