ما الذي ينتظره gateway-ping-timeout فعلاً في NetworkManager

تجد connection.gateway-ping-timeout في نقاش حول حاسوب محمول يقلع قبل أن تصبح الشبكة صالحة للاستخدام، فترفعه، فيتغير شيء ما. أما ما إذا كان التغيير قد ساعد للسبب الذي تظنه، فذلك سؤال منفصل. تبدأ الإجابة بما يفعله التنشيط فعلاً أثناء عمل ذلك المؤقت، وبكون الانتظار له نهايتان محتملتان.

تابع اتصالاً واحداً من سطر الأوامر وستصبح الدلالة ملموسة.

تابع عملية تنشيط واحدة

ابدأ بالنظر إلى الاتصال المحفوظ بدلاً من القيمة الافتراضية العامة، لأن هذه خاصية لكل اتصال على حدة. أضف --show-secrets فقط إذا كنت تحتاج إليه فعلاً؛ فالإعداد نفسه ليس سراً.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

عندما تكون الخاصية على صفر، وهو الافتراضي الموثق، يمضي التنشيط قدماً بمجرد اكتمال العنونة. اضبطها على قيمة موجبة فينتظر تنشيط إعداد IP حتى يصل رد من البوابة أو تنتهي المهلة.

ثم أنزل الاتصال وارفعه وأنت تراقب مجرى الأحداث. الترتيب الذي تراه هو الإعداد وهو يؤدي عمله: حالة الجهاز، ثم العنونة، ثم الانتظار، وأخيراً الحالة المنشطة التي تُرتَّب عليها الخدمات التابعة عادة.

للانتظار نهايتان

كلتا النهايتين مهمتان، ومعظم الناس يتذكرون واحدة فقط. الرد من البوابة ينهي الانتظار مبكراً، والمهلة تنهيه أيضاً، سواء أجاب شيء أم لم يجب. ولا تشترط الخاصية نجاح ping قبل أن يكتمل التنشيط.

تلك الجملة الواحدة توضح الكثير من الالتباس حول الحواسيب المحمولة في الفنادق وقاعات المؤتمرات، حيث ترفض بوابة الاشتراك غالباً ICMP حتى تسجل الدخول. يظل الاتصال يُنشَّط بعد انتهاء المهلة؛ لكنه يفعل ذلك بعد وقت أطول مما كان لازماً، وكل خدمة مرتبة بعد الاتصال تنتظر معه.

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

كائنان وإعداد واحد

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

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

اقرأ معرّفات UUID بدلاً من الأسماء. الأسماء تتكرر بعد إعادة تثبيت أو استعادة ملف شخصي، واتصالان لهما الاسم الظاهر نفسه سيدفعانك إلى تحرير الملف الخطأ بينما يبقى الملف الحقيقي دون تغيير.

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

ما لا يستطيع الانتظار إثباته

هذا هو الجزء الذي يستهلك أكبر وقت. الرد من الموجّه المحلي يثبت أن مضيفاً واحداً أجاب على صدى ICMP واحد أثناء التنشيط. ولا يثبت أن نقطة نهاية VPN تُحلَّل، ولا أن هوية العميل مقبولة، ولا أن المسارات الخاصة ثُبِّتت، ولا أن محلّل المكتب يجيب، ولا أن التطبيق الذي يهمك سيعمل.

تلك تبعيات منفصلة بأدلة منفصلة. فقد تجيب البوابة بينما يفشل DNS، وقد تُسقط البوابة ICMP بصمت حسب السياسة بينما يعمل كل مسار تطبيق. لذا فإن الاعتماد على هذه الخاصية كشرط هو تخمين لأي طبقة تأخرت، لا قياس لها.

إن كنت تنتظر خدمة تابعة، فسمِّ ما تحتاجه. العنوان المعيَّن يجيب عنه العنونة. والنفق يجيب عنه حالة النفق نفسه. والاسم الخاص يجيب عنه استعلام. والتطبيق يجيب عنه التطبيق، ولا شيء من تلك الإجابات يأتي من مؤقت سُمّي على اسم البوابة.

إن غيرته فاكتب السبب

سجّل القيمة السابقة والسبب قبل تغيير معتمد، ثم اضبطها على الاتصال المحدد لا في كل مكان. فالانتظار الأطول يزيح توقيت التنشيط لكل ما هو مرتب بعد ذلك الاتصال، وقد يجعل نظاماً بطيئاً يبدو جيداً ونظاماً سريعاً يبدو معطلاً.

ثمة فخ تاريخي يستحق الذكر: قيمة كهذه تُغيَّر أحياناً لجعل محرر أقدم يقبل ملفاً شخصياً. إن كانت هذه هي القصة الحقيقية، فلديك حدثان لا حدث واحد. فقد حفظ المحرر، وتغيرت سياسة شبكة حية. أصلح المحرر أو الملحق وأعد المؤقت.

يعرّف مصدر NetworkManager الخاصية على أنها تأخير لنجاح عنونة IP حتى رد البوابة أو انتهاء المهلة، مع افتراضي صفر، و تعريف إعداد الاتصال هو المرجع الذي تقرأه قبل الاعتماد على أي سلوك موصوف منقول.