إدخال وحدة SFP في المنافذ من 24 إلى 28 في DGS-1210-28 تحت OpenWrt لا يغيّر شيئاً، النحاس يحتفظ بالرابط
محوّل مختبر منزلي: D-Link DGS-1210-28 الإصدار F1 قمت بتحميل OpenWrt عليه لأتوقف عن مصارعة واجهة الويب الأصلية. كل شيء يعمل باستثناء المنافذ الأربعة الأخيرة، وهي منافذ مزدوجة نحاس/ألياف.
- المحوّل: D-Link DGS-1210-28 rev F1
- البرنامج الثابت: OpenWrt 21.02.0-rc3 (r16172-2aba3e9784)
- المنافذ 24-28: منافذ مزدوجة RJ45/SFP خلف شريحة PHY من نوع RTL8214FC (البقية تعمل على RTL8218B/RTL8218D)
- الوحدة: بصريات عامة بسرعة 1G ترتبط بشكل جيد في محوّل آخر
مهما وضعت في القفص، يتصرف المنفذ كمنفذ RJ45 عادي. جانب النحاس يبقى مُختاراً وجانب الألياف لا يرتفع أبداً:
# ethtool lan28
Supported ports: [ TP MII FIBRE ]
Port: MII
Link detected: yesسجل الإقلاع يُظهر فعلاً أن هذه المنافذ مربوطة بتعريف شريحة PHY المزدوجة RTL8214FC، ومن المفترض أن ذلك التعريف يعرف SFP، لذا يبدو الجانب العتادي سليماً.
ما جربته حتى الآن:
- أعدت تركيب الوحدة، ثم جرّبت وحدة ثانية
- سحبت كابل النحاس من المنفذ تماماً احتمالاً لوجود أولوية معينة - المنفذ يبقى على النحاس
- نقلت الوحدة إلى محوّل آخر، حيث ترتبط بنجاح
مع البرنامج الثابت الأصلي، كان هذا المحوّل يبدّل المنفذ إلى الألياف تلقائياً بمجرد إدخال وحدة. هل هناك طريقة لاختيار الوسط في هذا البناء (build)، أم أن المنافذ المزدوجة ببساطة غير قابلة للاستخدام بعد؟
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 3
لا شيء معطّل، ببساطة لا يوجد اختيار تلقائي للوسط في هدف realtek. شريحة RTL8214FC هي PHY مزدوجة بنصف نحاسي ونصف ألياف، وفي هذا البرنامج الثابت تبقى على جانب MII/النحاس حتى يُخبرها شيء بخلاف ذلك. إدخال وحدة لا يعني شيئاً للتعريف، لأن أحداً لم يُنفّذ آلية التبديل.
تختار الوسط بنفسك من مساحة المستخدم (userspace):
بعد ذلك يصبح القفص هو الوسط النشط على ذلك المنفذ وترتفع البصريات. لإعادة المنفذ إلى نصف RJ45:
نفس الاستدعاء لكل منفذ من المنافذ المزدوجة الأخرى، واحد لكل منفذ.
ما تتذكره من البرنامج الثابت الأصلي كان اختياراً تلقائياً محدوداً: كان ينظر إلى كلا النصفين ويفوز النحاس كلما كان لكلا الجانبين رابط. لهذا يبدو الأمر وكأنه تراجع، لكنه ليس كذلك - الوظيفة ببساطة لم تُكتب أبداً لهذا الهدف.
تحذيران. الأمر متاح فقط عبر سطر الأوامر، وغير مُتاح في LuCI، ويطلب الناس ذلك منذ فترة. ولا شيء في هذا البناء يختار الوسط نيابة عنك، لذا إن أردت الألياف بعد كل إقلاع، تأكد من أن ذلك الاستدعاء يُنفّذ فعلياً.
هذا هو الحل، شكراً لك. استدعاء واحد وتبدّل المنفذ:
ارتفعت البصريات فوراً وصمت نصف RJ45. فعلت الشيء نفسه للمنافذ الثلاثة المزدوجة الأخرى ووضعت الاستدعاءات الأربعة في سكربت إقلاع، بما أنه كما قلت لا شيء يتذكر الاختيار.
مزعج قليلاً أن مفتاحاً لكل منفذ يجب أن يعيش في سكربت شل، لكن المنافذ صارت قابلة للاستخدام الآن، وهذا ما كنت أحتاجه.
يستحق معرفته قبل أن تبني مراقبة فوق هذه المنافذ: حالة الرابط على جانب SFP في هذه اللوحات ليست موثوقة دائماً. في DGS-1210-10P لا توجد عقد sfp في شجرة الأجهزة (device tree) إطلاقاً، لذا لا يحصل النواة أبداً على إشارة وجود الوحدة أو فقدان الإشارة، وتُبلغ MAC عن حامل (carrier) دائم - يطبع
ip linkالقيمة<BROADCAST,MULTICAST,UP,LOWER_UP>لـ lan9 مع قفص فارغ، ويبقى مرفوعاً مع وحدة SFP نحاسية من نوع GLC-T-CO مركّبة وبدون كابل تصحيح فيها. أما DGS-1210-10MP فلا يتصرف بهذا الشكل، لأن DTS الخاص به يحتوي فعلاً على العقد.الإصلاح هناك كان تعديلاً في شجرة الأجهزة مبنياً على 10MP وعلى Zyxel GS1900-10HP: ناقل i2c-gpio لكل قفص، وعقدة sfp لكل قفص تتضمن los-gpio و mod-def0-gpio و tx-disable-gpio، مع
sfp = <&sfp0>مُشار إليها من المنفذ، وphy-mode = "1000base-x"وmanaged = "in-band-status". مع وجود هذه العناصر يُستقصى القفص عبر I2C ويتتبع الحامل أخيراً الإشارة البصرية الفعلية.على الصور الأصلية من تلك الفترة يستمر هذا السلوك، لذا إن كان أي شيء لديك يراقب الحامل على منفذ مزدوج أو منفذ SFP، تحقق من أنه يسقط فعلاً عند سحب الألياف.