جهاز Turris Omnia يُثبّت وحدة Luleey LL-XS2510 XPON على 1000baseX وأداة ethtool لا تعرض 2.5G أبدًا

انشر ناتج ethtool eth2 الكامل وأسطر sfp من dmesg، وليس فقط رسالة الرابط. الجزء المثير للاهتمام هو ما قرره المضيف بخصوص قدرات الوحدة: إذا استقر phylink على inband/1000base-x، فقد أخذ ذلك من EEPROM الوحدة نفسها، ولن يضيف أي إعداد على الموجّه نمطًا لم يره برنامج التشغيل أبدًا.

الفتحة على Omnia سليمة حتى 2.5G، لذا العتاد ليس ما يحدّك هنا. قل أيضًا ما إذا كان أي شيء تغيّر مؤخرًا على المضيف، بما في ذلك ترقية الصورة.

dmesg، متطابقة في كل إقلاع:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 تعطي 1000baseX/Full كمجموعتي الدعم والإعلان، وLink detected: yes بسرعة 1000Mb/s ازدواج كامل. لا يظهر شيء فوق 1G في أي مكان في الناتج.

أمر flash set LAN_SDS_MODE 6 على الوحدة يمر فعلاً ويصمد أمام إعادة تشغيل الوحدة، لكن جانب المضيف لا يتفاعل معه على الإطلاق: نفس الرسالة، نفس 1G. الموجّه على هذه الصورة منذ تركيب الوحدة، لذا لا يوجد شيء للعودة إليه.

هذا هو المضيف يأخذ كلام الوحدة كما هو. برنامج تشغيل sfp يقرأ EEPROM، يرى قطعة تُعلن 1000base-x، ويُثبّت eth2 على inband/1000base-x؛ عندها لا يملك phylink أي نمط 2.5G ليعرضه، وهو بالضبط ناتج ethtool الذي نشرته. ما تضبطه داخل RTL960x عبر LAN_SDS_MODE يمسّ serdes الخاص بالوحدة نفسها، وليس ما تُعلنه للموجّه، لذا لم يكن ليغيّر النمط المتفاوض عليه أبدًا.

طريقان للخروج، وأنا أعرف هذين فقط. إما إعادة كتابة EEPROM الوحدة حتى تُعلن 2.5G، وهي الحيلة المعروفة على DFP-34X-2C3، لكن وحدتك من نوع 2C2 ولن أفترض نفس الإزاحات. أو تعديل المضيف: أضف استثناءً لهذه الوحدة في sfp.c وشغّل نواة تحتوي عليه، تاركًا الوحدة كما هي.

من حيث الميزان، أفضّل تعديل المضيف. EEPROM معطوب في وحدة لا يمكنك إعادة برمجتها بسهولة هو أسوأ بكثير من نواة يمكنك العودة عن إصدارها.

سبب آخر لإبقاء الشك على المضيف بدلاً من الوحدة. على لقطات OpenWrt كانت هناك فترة كسر فيها كود التحقق العام لـ phylink الذي تم نقله من فرع آخر فتحة SFP على Omnia تمامًا: كانت ethtool لا تزال تُعلن 2500baseX/Full بينما المنفذ يبلّغ فقط Link detected: no. تم عزل السبب بدقة إلى تلك المُراجعة (commit) في النواة، وإزالة النقل أعادت الرابط عند 2500Mb/s ازدواج كامل، وأغلق إصلاح لاحق المشكلة.

عرض مختلف عن عرضك، نفس الدرس. على ألواح mvneta وphylink، برنامج المضيف هو من يقرر ما يُسمح للفتحة بفعله، ويستحق الأمر الاحتفاظ بصورة معروفة الصلاحية للعودة إليها قبل أن تبدأ ببناء نواتك الخاصة.

إذا سلكت طريق النواة المخصصة على Turris OS، خذ لقطة أولاً: schnapps create "Before new kernel"، ثم opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk وأعد التشغيل. إذا أساءت النواة التصرف تعود بدلاً من تفكيك الموجّه.

الأمر الثاني الذي لا يذكره أحد إلا لاحقًا: رابط بسرعة 2.5 جيجابت ليس 2.5 جيجابت من حركة المرور. معالج Armada في Omnia لن يدفع ذلك على طابور واحد، لذا خطط لتوجيه الحزم وضبط RPS قبل أن يتحول الرقم على السلك إلى إنتاجية فعلية.

فخ غير متعلق لأي شخص آخر يقرأ هذا بوحدة مختلفة: بعض وحدات PON تُشغّل نظام تشغيل خاصًا بها وتحتاج حوالي دقيقة قبل أن تستجيب على الإطلاق، لذا في الإقلاع البارد يفحص الموجّه الفتحة مبكرًا جدًا ويعود إلى المغناطيسية النحاسية. fw_setenv bootdelay 60 في U-Boot هو العلاج المعتاد. ليست حالتك، لأن وحدتك تُكتشف فورًا.

إغلاق الحلقة: فاز تعديل المضيف. بنيت نواة بملف sfp.c معدّل، أخذت لقطة schnapps أولاً، ثبّت ملف ipk بخيار --force-reinstall وأعدت التشغيل. ethtool eth2 الآن تُدرج 2500baseX/Full ويعمل الرابط بسرعة 2.5 جيجابت.

لم يُفعل شيء بالوحدة في النهاية. بقي LAN_SDS_MODE كما كان وتبيّن أنه غير ذي صلة، فلم أضطر أبدًا لمس EEPROM.

الإنتاجية احتاجت النصيحة الثانية أيضًا. مباشرة بعد إعادة التشغيل كان الجهاز أقل بكثير من سرعة الرابط على طابور واحد؛ وبعد ضبط توجيه الحزم أصبح WAN أخيرًا يفعل ما اشتُريت الوحدة من أجله.