NetworkManager में gateway-ping-timeout वास्तव में किस बात का इंतज़ार करता है

आप 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 कॉन्फ़िगरेशन का एक्टिवेशन तब तक इंतज़ार करता है जब तक गेटवे से जवाब न आए या टाइमआउट खत्म न हो जाए।

फिर इवेंट स्ट्रीम देखते हुए कनेक्शन को डाउन और अप करें। आप जो क्रम देखते हैं वही सेटिंग का काम है: डिवाइस की स्थिति, एड्रेसिंग, इंतज़ार, और अंत में वह सक्रिय स्थिति जिसके मुताबिक डिपेंडेंट सेवाएं आमतौर पर क्रम में लगाई जाती हैं।

इस इंतज़ार के दो अंत हैं

दोनों अंत मायने रखते हैं, और ज्यादातर लोग सिर्फ एक याद रखते हैं। गेटवे से जवाब इंतज़ार को जल्दी खत्म कर देता है, और टाइमआउट भी उसे खत्म कर देता है, चाहे किसी ने जवाब दिया हो या नहीं। प्रॉपर्टी यह नहीं मांगती कि एक्टिवेशन पूरा होने से पहले पिंग सफल हो।

यह एक वाक्य होटलों और सम्मेलन स्थलों के लैपटॉप के बारे में बहुत भ्रम दूर करता है, जहां कैप्टिव पोर्टल अक्सर तब तक ICMP मना करता है जब तक आप लॉग इन न करें। टाइमआउट खत्म होने के बाद भी कनेक्शन सक्रिय होता है; बस यह जरूरत से देर से होता है, और कनेक्शन के बाद क्रम में रखी हर सेवा इसके साथ इंतज़ार करती है।

यह जीवंतता की जांच भी नहीं है। विवरण में कुछ भी कनेक्शन के बाद गेटवे को पिंग करना शुरू नहीं करता, और कोई भी बाद में पिंग फेल होने पर सक्रिय प्रोफ़ाइल को डिस्कनेक्ट नहीं करता। अगर आपको लॉस डिटेक्शन चाहिए, तो वह प्रोटोकॉल या टनल के मालिक का काम है, उस प्रॉपर्टी का नहीं जो एक्टिवेशन के दौरान एक बार चली।

दो ऑब्जेक्ट, एक सेटिंग

वायर्ड बेस प्रोफ़ाइल और 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-एड्रेसिंग की सफलता में गेटवे जवाब या टाइमआउट तक की देरी के रूप में परिभाषित करता है, डिफ़ॉल्ट शून्य के साथ, और कनेक्शन सेटिंग की परिभाषा वह संदर्भ है जिसे किसी भी दूसरे हाथ से बताए गए व्यवहार पर भरोसा करने से पहले पढ़ना चाहिए।