عصا FS GPON ONU في مقبس SFP+ على UDM-Pro: لا طريقة للوصول إلى عنوان إدارتها لكتابة الرقم التسلسلي

Asked 19 days ago Active 17 days ago Viewed 93 AI translation from English

إعداد منزلي، وأحاول التخلص من جهاز التوجيه الخاص بالمزوّد على خط GPON من Cosmote. الفكرة هي إيصال الألياف مباشرة إلى UDM-Pro وترك العصا تقوم بمهمة ONU، لكن المزوّد يقبل الجلسة فقط إذا قُدِّم الرقم التسلسلي المكوّن من 12 حرفًا وسلسلة طراز الجهاز الخاصة بمعدات العميل (CPE) القديمة، لذا يجب أن أدخل إلى الوحدة وأكتب كليهما.

Ubiquiti UDM-Pro، العصا في منفذ SFP+ رقم 10
عصا FS GPON ONU بـMAC SFP، الصنف 133619
كابل وصل SC/APC إلى SC/APC من علبة الحائط
معدات العميل القديمة (CPE) ما زالت على المكتب كمرجع للرقم التسلسلي وسلسلة الطراز

مشكلتي أساسية أكثر من الاستنساخ نفسه: لا أستطيع الوصول إلى الوحدة إطلاقًا. من غلاف الجهاز البوابة (gateway shell) لا شيء يجيب على عنوان إدارتها.

ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10

الأمر الثاني يبقى معلقًا حتى يستسلم. لا لافتة (banner)، لا رفض اتصال، لا شيء.

ما فعلته بالفعل:

أعدت تركيب العصا وبدّلت كابل الوصل، الوحدة تعمل ومصباحها يتصرف بشكل طبيعي
تأكدت أن لا شيء على UDM-Pro يستخدم 192.168.1.0/24، شبكتي المحلية على نطاق فرعي مختلف
فكرت في بناء VLAN إدارة مخصص للمقبس، لكن هذا الكثير من العمل لكتابة واحدة

هل هناك طريقة لمخاطبة مقبس SFP مباشرة من غلاف UDM-Pro بحيث أستطيع تسجيل الدخول إلى العصا وكتابة الرقم التسلسلي ومعرّف الجهاز، دون إنشاء VLAN منفصل له؟

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 简体中文

sfpnode CN

Comments 4

Accepted answer

شيئان منفصلان يعترضان طريقك، ولا واحد منهما هو الوحدة.

أولًا، المخاطبة (addressing). مقبس SFP هو واجهة عادية على UDM-Pro، مرقّمة كرقم المنفذ المعروض ناقص واحد، لذا فإن المنفذ 10 هو eth9. أعطِ البوابة عنوانًا داخل النطاق الفرعي للوحدة وتأكد من أن الردود تأتي منه:

ip addr add dev eth9 local 192.168.1.2/24
iptables -t nat -A POSTROUTING -o eth9 -d 192.168.1.0/24 -j SNAT --to 192.168.1.2

بعد ذلك يجيب 192.168.1.10 من غلاف البوابة.

ثانيًا، المصافحة (handshake). البرنامج الثابت على هذه العصي قديم بما يكفي بحيث تتوقف قائمة تبادل المفاتيح عنده عند الخوارزميات القديمة، لذا عليك تسمية واحدة صراحة:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ONTUSER@192.168.1.10

بمجرد الدخول، يُكتب الرقم التسلسلي الخاص بالمزوّد بـset_serial_number AVMGXXXXXXXX ويُستنسخ سلسلة طراز الجهاز بـsfp_i2c -i7 -s. أعد تشغيل العصا وتحقق مما ثبت فعليًا:

fw_printenv | grep nSerial

تحذيران. لا شيء من هذا إعداد مدعوم - أنت تضيف يدويًا عنوانًا وقاعدة NAT على جهاز مُدار، لذا تعامل معه كأنبوب مؤقت لجلسة البرمجة واحتفظ بمعدات العميل القديمة حتى يُصادق الخط. النصف الآخر من التحذير يخص السرعة: 2.5 غيغابت ليس شيئًا ستوافق عليه هذه المنصة من تلقاء نفسها، لذا حتى وحدة تعلن عن 2.5G تنتهي مقترنة إما بـ1G أو 10G. إذا كنت تفضّل عدم لمس البوابة إطلاقًا، فالبديل هو برمجة العصا في جهاز آخر بمنفذ SFP موجَّه (routed) ثم نقلها لاحقًا.

edgepilotID 19 days ago Show original (English) AI translation

ماذا تسمي البوابة نفسها ذلك المقبس؟ على هذا الجهاز منافذ SFP هي واجهات عادية، لكن التسمية لا تتطابق مع الأرقام المطبوعة على اللوحة الأمامية، لذا من السهل أن تدفع حزمًا خارج شيء ليس المقبس إطلاقًا - ومن الغلاف يبدو ذلك بالضبط مثل ما حصلت عليه، جلسة معلقة بلا شيء في الطرف الآخر.

ألصق قائمة الواجهات من غلاف البوابة. بمجرد اتضاح أي واجهة تنتمي إلى ذلك المنفذ، جزء المخاطبة هو النصف السهل.

coreadminDE 19 days ago Show original (English) AI translation

eth9 كانت هي بالضبط، المنفذ 10 ناقص واحد. العنوان بالإضافة إلى قاعدة SNAT جعلا 192.168.1.10 يجيب من المحاولة الأولى، وخيار تبادل المفاتيح القديم كان النصف الآخر من الحل: بدون تلك العلامة استسلم عميلي أثناء المصافحة، ومعها حصلت على موجّه ONTUSER فورًا.

كتبت الرقم التسلسلي بـset_serial_number AVMGXXXXXXXX، واستنسخت سلسلة الطراز بـsfp_i2c -i7 -s، وأعدت التشغيل، وأعطاني fw_printenv | grep nSerial القيمة التي ضبطتها. صادق الخط بعد بضع دقائق ومعدات العميل القديمة مفصولة الآن.

شيء واحد تأكد بالطريقة الصعبة: عمل المنفذ بسرعة 1G، تمامًا كما حُذّر بخصوص 2.5G على هذا المقبس. مناسب للباقة التي يعطيني إياها المزوّد هنا.

sfpnodeCN 18 days ago Show original (English) AI translation

نفس المهمة، قطع مختلفة، والرقم التسلسلي هو حيث يصبح الأمر مزعجًا. كنت أنقل هوية Calix GigaPoint 801Gv2 إلى عصا G-010S-A بأداة ritool:

ritool set MfrID 3720
ritool set G984Serial 10010470
ritool set YPSerialNum 10010470

الرقم التسلسلي للـONT هو 372010010470، لكن الوحدة سجّلته مجددًا كـ

read_sn_from_RI sn is: 3720101470

أقل بصفر واحد. السبب هو تخطيط الحقل: الرقم التسلسلي لـGPON هو 8 بايتات، الأربعة الأولى تحمل معرّف المورّد كأحرف ASCII (3720 تُقرأ حرفيًا كأربعة حروف) والأربعة الأخيرة تحمل الجزء الرقمي معبأً كسداسي عشري (hex). ذيل عشري مثل 10010470 لا يدخل رقمًا برقم، وهذا سبب فقدان الصدى لحرف.

إذن قبل إعلان النصر، تحقق من كيفية تسجيل مزوّدك لجهاز ONT في المقام الأول - الرقم التسلسلي أم SLID / معرّف التسجيل. كتابة الرقم التسلسلي وحده ليس دائمًا ما يطابقونه عليه.

optictechES 17 days ago Show original (English) AI translation