عصا ALLNET ALL4781-VDSL2-SFP في جهاز Turris Omnia تعيد المزامنة كل 30 إلى 120 دقيقة
أخيراً نقلت خط VDSL2 لدي بعيداً عن جهاز مزود الخدمة وأنهيته على جهاز Turris Omnia نفسه، بشكل أساسي حتى تعمل PPPoE على الراوتر بدلاً من جهاز ثانٍ في وضع الجسر (bridge). جزء الإعداد كان سهلاً: ركّب العصا في المقبس (cage) وواجهة WAN تنتقل ببساطة إلى الوحدة، تاركةً المقبس المعدني خارج الصورة، مع ارتفاع الرابط الداخلي من تلقاء نفسه. المؤشر الأخضر يتتبع مزامنة DSL، والبرتقالي الجانب المواجه للراوتر.
- Turris Omnia، PPPoE مُعدّة على الواجهة المواجهة للمودم
- عصا مودم ALLNET ALL4781-VDSL2-SFP في مقبس SFP
- خط VDSL2 يتدرب على السرعة الكاملة 100 ميجابت تنازلياً
option ifname 'eth1.7'، لأن خطي يحتاج وسم VLAN 7
عشر دقائق من الإعداد بالإضافة إلى إعادة تشغيل وكان الخط يعمل بمعدل الخط الكامل. المشكلة أنه لا يبقى كذلك. في مكان ما بين نصف ساعة وساعتين تفقد DSL المزامنة، وتحتاج من دقيقتين إلى ثلاث دقائق للعودة:
LCP terminated by peer
Modem hangup
eth1: link is downما قمت به بالفعل:
- أعدت تركيب العصا وأعدت تشغيل الراوتر، والفاصل الزمني بعد ذلك هو نفسه
- استبدلت كابل توصيل DSL ونقلت العصا إلى المقبس الأول على الخط
- فصلت كابل WAN النحاسي حتى لا يتنازع شيء على الواجهة
لا شيء من ذلك غيّر النمط. هل هذه مشكلة في العصا، أم في خطي، أم في طريقة تعامل Omnia مع المقبس؟ هل يشغّل أحد هذه العصا لفترة طويلة دون انقطاع المزامنة؟
Comments 4
هذا هو المزيج السيء المعروف: البرمجية الثابتة 3.4 على خط قادر فعلياً على 100 ميجابت. العصا ليست معطوبة بحد ذاتها - جهاز Omnia آخر أعرفه يشغّل نفس الوحدة على خط VDSL2 بملف (profile) 17a منذ فترة طويلة ولم يفقد المزامنة ولو مرة واحدة، وهذا هو سبب انقسام التقارير حول هذا الأمر بهذا الشكل. أي خط ينتمي إلى أي مجموعة ليس أمراً يمكن معرفته من ورقة البيانات مسبقاً.
أمران، بهذا الترتيب.
أولاً، توجه إلى المُصنّع بخصوص البرمجية الثابتة. لقد اعترفوا بأن 3.4 تسيء التصرف عندما يستطيع الخط الوصول إلى 100 ميجابت، والنسخة الأحدث مجانية، فلا سبب لعدم تشغيلها.
ثانياً، استمر بمراقبة المؤشرات بعد ذلك. انطفاء الأخضر أولاً يعني DSL، والبرتقالي يعني جانب المقبس. إذا استمر الأخضر بالانقطاع على النسخة الأحدث، فالبرمجية الثابتة لم تكن كل القصة في خطك.
بصراحة بخصوص النتيجة، لأنك ستسأل على أي حال: أعرف خطاً واحداً على الأقل حيث لم يغيّر التحديث شيئاً واستمرت المزامنة بالانقطاع بنفس الفاصل من ثلاثين دقيقة إلى ساعتين. يبدو أن الاستقرار مع هذه العصا يعتمد على خصائص الخط بقدر اعتماده على النسخة، لذا تعامل مع البرمجية الثابتة كأرخص شيء تجربه وليس كحل مضمون. إذا استمر الانقطاع بعد ذلك، فالحل غير الأنيق هو إعادة وضع مودم في المقدمة والإبقاء على جلسة PPPoE على الراوتر عبر
eth1.7- تحتفظ بالإعداد الذي لديك وتتوقف عن مطاردة المزامنة.ما هي البرمجية الثابتة الموجودة على العصا؟ هناك أكثر من نسخة متداولة ولا تتصرف بنفس الطريقة على الخطوط السريعة، فهذا أول شيء يجب تحديده.
أمران آخران قبل أن تلوم الراوتر. في لحظة الانقطاع، هل ينطفئ المؤشر الأخضر، أم يبقى مضاءً بينما يتحرك البرتقالي؟ هذا يخبرك ما إذا كانت مزامنة DSL قد فُقدت أم أن الرابط نحو Omnia فقط هو المتأثر. وهل يمكنك الحصول على أي شيء مفيد من العصا نفسها في الدقائق التي تسبق الانقطاع - المعدل القابل للتحقيق (attainable rate)، هامش SNR، عدادات الأخطاء؟ مزامنة تحافظ على معدلها حتى اللحظة التي تموت فيها تُقرأ بشكل مختلف تماماً عن واحدة تتراجع تدريجياً أولاً.
البرمجية الثابتة 3.4 على العصا.
جلست بجانب الجهاز والتقطت ثلاث حالات انقطاع متتالية: الأخضر ينطفئ أولاً، والبرتقالي يبقى مضاءً طوال الوقت. إذن الرابط نحو الراوتر لا يتحرك أبداً، بل مزامنة DSL هي التي تموت وتتبعها جلسة PPPoE في السقوط. هذا أيضاً يجعل
LCP terminated by peerنتيجة وليست سبباً، وهو ما اشتبهت به لكن لم أثبته.بخصوص العدادات ليس لدي شيء أقدمه لك. المعدل القابل للتحقيق، الهامش، عدادات الأخطاء - العصا لا تكشف عن أي منها في أي مكان أستطيع الوصول إليه، والراوتر يعرض لي معدل المزامنة فقط ولا شيء آخر. هذا الرقم يبقى عند معدل الخط الكامل حتى اللحظة التي يختفي فيها، فلا شيء يتراجع تدريجياً أولاً، بل يختفي ببساطة. الملف (profile) لم يتغير أيضاً منذ أن كان مودم مزود الخدمة أمام الخط.
عصا مختلفة، نفس المقبس، يستحق المعرفة بينما تختبر.
كان لدي عصا HALNy HL-GSFP GPON في جهاز Omnia: النواة (kernel) التقطتها دون شكوى، وتحول المنفذ إلى inband/1000base-x، ثم بقي eth2 في حالة down إلى الأبد. المسألة توقيت، وليست توافقاً. الوحدة تحمل نظام تشغيل صغيراً خاصاً بها وتحتاج قرابة الدقيقة كاملة قبل أن تستجيب لأي شيء، بينما يتم فحص المقبس بعد ثوانٍ قليلة من التشغيل. الفحص لا يجد أحداً، فيبقى الراوتر بهدوء على WAN المعدني ولا تستيقظ واجهة SFP أبداً. الأمر
fw_setenv bootdelay 60في u-boot حلّ المشكلة نهائياً.هذا لن يفسر انقطاع المزامنة في منتصف جلسة، فهو ليس إجابتك. لكن إذا أعدت التشغيل يوماً بعد انقطاع ووجدت نفسك عائداً إلى النحاس، فهذه هي الآلية التي تنظر إليها، وليست وحدة معطوبة.