عصا GPON من طراز DFP-34X-2C2 تظهر في dmesg فقط بعد عشرات الثواني ثم تعمل بلينك 1G
أقوم باستبدال ONT الخاص بالمشغل بعصا GPON من نوع SFP على جهاز Linux الذي ينهي شبكة WAN لدينا، والعصا لا تتصرف مثل ترانسيفر إطلاقًا. أدخلها ويبقى القفص صامتًا لنصف دقيقة أو أكثر، طويل بما يكفي لأفترض مرتين أن الوحدة معطلة، وعندما تلاحظها النواة (kernel) أخيرًا يستقر اللينك عند سرعة جيجابت، مما يفوّت الغرض من العملية.
إعداد العمل:
- جهاز راوتر Linux، قفص SFP يديره طبقة SFP في النواة، نواة رئيسية (mainline kernel)
- عصا ODI DFP-34X-2C2 GPON
- عصا Huawei MA5671a كعينة ثانية
- وحدة فايبر 1G عادية تظهر فورًا في نفس القفص، لذا القفص نفسه سليم
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offما جربته حتى الآن:
- إعادة تركيب العصا وتركها دون لمس لعدة دقائق قبل لمس الواجهة، والانتظار موجود في كل مرة، وليس فقط عند الإدخال الأول
- إعادة تشغيل الواجهة بعد الاكتشاف، وهو ما لا يغيّر شيئًا في وضع التفاوض
- تُظهر MA5671a نفس الظهور البطيء، لذا الأمر ليس عينة واحدة معطوبة
هل هذا ببساطة كيف تتصرف عصي GPON على مضيف Linux، أم أن جانبي يفعل شيئًا خاطئًا؟ ماذا يحدث فعليًا بين الإدخال والاكتشاف هنا؟
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 7
قبل أن يبدأ التخمين، شيئان يستحقان التحديد. أولًا، انشر dmesg الكامل غير المقصوص من الإدخال فصاعدًا بدلًا من grep بسطرين. تقول إن القفص يقع خلف طبقة SFP في النواة وليس لدي سبب للشك في ذلك، لكن الأسطر التي قمت بتصفيتها هي التي تُظهر كم مرة تم فحص الوحدة، وما الذي استسلم في الأثناء وكم استغرقت كل محاولة.
ثانيًا، ماذا تدّعي الواجهة نفسها أنها قادرة عليه بمجرد أن تعمل العصا أخيرًا، وهل يظهر 2500baseX في أي مكان ضمن الأوضاع المعلنة؟ وما السرعة التي يعطيك إياها مزود الخدمة على جانب PON، لأنه إذا كانت تلك خطة جيجابت فإن اللينك الذي تحصل عليه هو الصحيح ولا شيء يحتاج إصلاحًا.
سلوك متوقع، للأسف، وليس مضيفك.
عصا GPON ليست ترانسيفر بشريحة EEPROM بداخلها. إنها حاسوب Linux صغير على SoC خاص بها، مضغوط داخل غلاف SFP، وEEPROM الذي يقرأه مضيفك عبر I2C يُحاكيه ذلك النظام. لا شيء يجيب على الناقل حتى يقلع فيرموير العصا الخاص بها بما يكفي لخدمة تلك الصفحات، وهذا سبب جلوسك هناك لعشرات الثواني بينما تجيب الوحدة العادية فورًا. ذلك الصمت قبل سطر الوحدة الخاص بك هو الإقلاع.
النصف الثاني من مشكلتك هو أن ما تعلنه الصفحات المُحاكاة غالبًا ما يكون خاطئًا ببساطة. الواجهة على جانب المضيف في هذه العصي هي 2500BASE-X، وEEPROM يقول شيئًا آخر، لذا تأخذ طبقة SFP ذلك على ظاهره وتستقر على وضع الجيجابت. كلا النصفين يُعالَجان في النواة بحيل خاصة (quirks) لكل وحدة بدلًا من أي شيء يمكنك تكوينه، وقد حصلت DFP-34X-2C2 الأصلية (OEM) على واحدة من تلك الحيل لهذا السبب بالضبط.
ما إذا كانت عينتك تقع ضمنها يعتمد على نصوص المورّد والقطعة التي تبلغ عنها، وهذه تختلف بين إعادات التسمية (rebadges)، لذا قارن ما يطبعه سطر dmesg الخاص بك مع ما تطابقه الحيلة قبل افتراض أنك مشمول.
للتأكيد على سبب الحاجة إلى نهج الحيل (quirks) أصلًا: SFF-8472 يفترض جهاز ذاكرة سلبي يجيب ضمن توقيتات I2C العادية. لا شيء فيه يتوقع جهازًا يحتاج نصف دقيقة من الإقلاع قبل أن يتمكن من التحدث، لذا فإن المضيف الذي يتبع المعيار له كل الحق في التخلي عن الوحدة أو الثقة ببتات الوضع التي يقرأها في النهاية.
نقطة إعادة التسمية أعلاه هي الفخ العملي. المطابقة تتم على نصوص المورّد والقطعة، لذا فإن نفس العصا الفيزيائية المُباعة تحت اسم مختلف تفوت الحيلة تمامًا وتعود إلى لينك جيجابت دون سبب واضح. ولا تبنِ أي شيء يعتمد على وجود الوحدة بعد وقت قصير من الإقلاع، لأن ذلك السباق غير قابل للفوز هنا.
الأمل في أن يصلح موردو العصي محتويات EEPROM الخاصة بهم متفائل أيضًا. عندما أُثيرت هذه المشاكل، حصل حتى مزودو خدمة كبار على استجابة ضعيفة جدًا منهم.
نفس فئة المشكلة تظهر على أجهزة توجيه المستهلكين، لذا على الأقل أنت لست وحدك. مالكو Archer BE800 وَBE900 وَGE800 مع عصا في منفذ 10G SFP+ المشترك (combo) يحصلون على 1 جيجابت بالثانية بدلًا من 2.5 التي يدفعون ثمنها، وقائمة TP-Link الخاصة بالعصي المُبلَّغ عن عملها في تلك المنافذ هي ODI DFP-34X-2C2 وَHuawei MA5671A وَNokia G-010SA، وهي نفس القائمة القصيرة من القطع التي ينتهي بها الأمر مع الجميع.
نصيحة الخط الأول هناك كانت الفيرموير بالإضافة إلى إعادة التركيب، وجزء إعادة التركيب ليس هراءً، فوحدة لم تُثبَّت تمامًا في مكانها تتراجع فعليًا. الإصدارات التجريبية (beta) كشفت في النهاية عن تكوين المنفذ، واحد لكل طراز:
مع وجود أحدها على الجهاز يصبح وضع منفذ SFP قابلًا للضبط عبر telnet، مع إسقاط الواجهة أولًا،
ip link set eth1 downوهكذا.لا يزال حلًا بديلًا وليس إصلاحًا، مع ذلك. بعد عام، وردت نفس الشكاوى، وليس فقط حول العصي: شخص واحد كان لديه AOC من طراز JT-AOC-SFP-15 من JT-COM في ذلك المنفذ، وآخر كابل DAC سلبي 10G SFP+ من Ampcom، وكلاهما استقر عند 1 جيجابت بالثانية.
يستحق معرفة نمط الفشل الآخر قبل أن يقترح أحد نقل العصا إلى بطاقة NIC. على OpenWrt 19.07 على x86 مع Intel X520 وَkmod-ixgbe، تُرفض MA5671a ببساطة كـSFP غير مدعوم. ضبط allow_unsupported_sfp عبر ملفات تكوين الوحدات المعتادة لا يفعل شيئًا هناك إطلاقًا، يجب إعطاء المعامل عند تحميل الوحدة:
وحتى مع ذلك لا يزال التعريف يرفضها، لأن EEPROM الخاص بالعصا لا يصف ترانسيفرًا عاديًا من الأساس والعلم (flag) لا يستطيع التستر على ذلك. إذا انتهى بك الأمر على بطاقة NIC، أثبت سلامة المنفذ بوحدة 1000BASE-T أو LX أو SX عادية أولًا، وإلا فأنت تستكشف أخطاء البطاقة والعصا في وقت واحد.
احذر من تشغيل هذين معًا رغم ذلك. allow_unsupported_sfp يعيش داخل ixgbe ويقرر ما إذا كان ذلك التعريف مستعدًا لتشغيل بصريات معينة على الإطلاق، وهذا قرار مختلف عن القرار المتخذ هنا. الانتظار الطويل والوضع الخاطئ يأتيان من طبقة SFP العامة التي تقرأ الصفحات المُحاكاة وتسلّم النتيجة إلى phylink، وهناك تقع حيل كل وحدة على حدة.
على لوحة بها قفص SFP مناسب، لا يوجد علم ixgbe أصلًا وليس هو الإصلاح، وعلى X520 لن تنقذك قائمة الحيل أيضًا. نفس العرض على السطح، طبقة مختلفة تحته، والخلط بينهما هو كيف ينتهي بالناس إعادة بناء التعريفات دون فائدة.
حد آخر يستحق رسمه بينما أنت في الموضوع: جعل المضيف يرى العصا وجعل OLT يقبلها مشكلتان مستقلتان، والثانية يمكن أن تكون أسوأ بكثير.
هناك حالة موثّقة جيدًا لعصا Xicom DFP-34X-2C2 محمّلة بهوية منسوخة من ZTE ZXHN F601 باستخدام setmac واستعلامات OMCI، الرقم التسلسلي GPON، كلمة مرور PLOAM، LOID، الرقم التسلسلي للجهاز ونص الفيرموير، كل ذلك. تصل العصا إلى حالة O5 ثم تبقى هناك فقط، لا يُخصَّص أي معرّف ONU ولا حركة مرور، لأن الوصول إلى O5 يعني فقط أن عملية الـranging نجحت بينما لا يزال يجب أن يطابق تحميل MIB ملف تعريف ONT الذي يتوقعه OLT. لم يقدم أحد في ذلك الموضوع حلًا.
إذن عندما تحصل فعلًا على 2500BASE-X محليًا، لا تفترض أن الجزء الصعب انتهى. حيث يربط المشغل ملف تعريف الخدمة بطراز ONT محدد، قد لا توجد مجموعة من الحقول المنسوخة تجعل عصا من طرف ثالث مقبولة.