Mire vár valójában a gateway-ping-timeout a NetworkManagerben

Akkor találkozik connection.gateway-ping-timeout egy olyan szálban, amely egy laptopról szól, amely még a hálózat használhatósága előtt elindul, megemeli, és valami megváltozik. Hogy a változás a feltételezett ok miatt segített-e, külön kérdés. A válasz ott kezdődik, hogy az aktiválás valójában mit tesz, miközben ez az időzítő fut, és ott, hogy a várakozásnak két lehetséges vége van.

Kövessen végig egy kapcsolatot a parancssorból, és a szemantika kézzelfoghatóvá válik.

Kövessen végig egy aktiválást

Kezdje a mentett kapcsolat megtekintésével, ne egy globális alapértékkel, mert ez kapcsolatonkénti tulajdonság. Adja hozzá a --show-secrets kapcsolót csak akkor, ha valóban szüksége van rá; maga a beállítás nem titok.

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

Ha a tulajdonság nulla, ami a dokumentált alapérték, az aktiválás továbbhalad, amint a címzés befejeződik. Állítson be pozitív értéket, és az IP-konfiguráció aktiválása addig vár, amíg válasz nem érkezik az átjárótól vagy le nem jár az időtúllépés.

Ezután hozza le és fel a kapcsolatot, miközben figyeli az eseményfolyamot. A látott sorrend a beállítás munkája: eszközállapot, címzés, a várakozás, végül az aktivált állapot, amelyhez a függő szolgáltatásokat általában rendelik.

A várakozásnak két vége van

Mindkét vég számít, és a legtöbb ember csak egyre emlékszik. Az átjárótól érkező válasz korábban befejezi a várakozást, és az időtúllépés is befejezi, akár válaszolt valami, akár nem. A tulajdonság nem ír elő sikeres pinget az aktiválás befejezése előtt.

Ez az egy mondat sok zavart oszlat el a szállodai és konferenciaközpontokbeli laptopokkal kapcsolatban, ahol a captive portal gyakran visszautasítja az ICMP-t, amíg be nem jelentkezik. A kapcsolat az időtúllépés lejárta után is aktiválódik; csak később teszi, mint kellene, és minden, a kapcsolat után sorba állított szolgáltatás vele együtt vár.

Ez nem életjel-ellenőrzés sem. A leírásban semmi sem kezd el pingelni egy átjárót, miután a kapcsolat felállt, és semmi sem bont egy aktív profilt azért, mert egy későbbi ping meghiúsul. Ha veszteségészlelésre van szüksége, az a protokoll vagy az alagút tulajdonosának dolga, nem egy olyan tulajdonságé, amely egyszer futott le az aktiválás alatt.

Két objektum, egy beállítás

A vezetékes alap-profil és a VPN-profil külön konfigurációs objektumok, és a tulajdonság beállítása az egyiken nem hat a másikra. Az alap-kapcsolatot megnevező VPN-profil nem örökli annak egyetlen aktiválási beállítását sem, ezért tűnhet úgy, hogy a módosított értéknek nincs hatása arra, amit figyelt.

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

A nevek helyett az UUID-kat olvassa. A nevek megduplázódnak újratelepítés vagy visszaállított profil után, és két azonos látható nevű kapcsolat miatt a rossz fájlt szerkeszti majd, miközben a valódi változatlan marad.

A telepített NetworkManager-kiadás is számít. A bővítmény viselkedése és az, hogy egy kapcsolattípus hogyan képezi le ezt a tulajdonságot a saját aktiválási lépéseire, változik, ezért a telepített verzió tesztelje, ne feltételezze, hogy egy talált bejegyzés változatlanul érvényes.

Mit nem tud igazolni a várakozás

Itt van a legtöbb időt felemésztő rész. A helyi útválasztó válasza bizonyítja, hogy egy gazdagép válaszolt egy ICMP-visszhangra az aktiválás alatt. Nem bizonyítja, hogy egy VPN-végpont feloldódik, hogy a kliens identitását elfogadják, hogy privát útvonalak telepítődtek, hogy az irodai feloldó válaszol, vagy hogy a fontos alkalmazás működni fog.

Ezek külön függőségek, külön bizonyítékokkal. Egy átjáró válaszolhat, miközben a DNS hibázik, és egy átjáró csendben eldobhatja az ICMP-t szabályzat alapján, miközben minden alkalmazási útvonal működik. Ezért erre a tulajdonságra kapuzni találgatás arról, melyik réteg késik, nem annak mérése.

Ha egy függő szolgáltatásra vár, nevezze meg, mire van szüksége. A kiosztott címet a címzés válaszolja meg. Az alagutat az alagút saját állapota válaszolja meg. A privát nevet egy lekérdezés válaszolja meg. Az alkalmazást az alkalmazás válaszolja meg, és e válaszok egyike sem olyan időzítőtől jön, amelyet az átjáróról neveztek el.

Ha módosítja, írja le, miért

Jegyezze fel az előző értéket és az okot a jóváhagyott változtatás előtt, majd a konkrét kapcsolaton állítsa be, ne mindenhol. A hosszabb várakozás eltolja az aktiválás időzítését mindenre, ami az adott kapcsolat után van sorba állítva, ami miatt egy lassú rendszer jónak, egy gyors pedig hibásnak tűnhet.

Egy történelmi csapdát érdemes megnevezni: egy ilyen értéket néha azért változtatnak meg, hogy egy régebbi szerkesztő elfogadjon egy profilt. Ha ez a valódi történet, két eseménye van, nem egy. A szerkesztő mentett, és egy élő hálózati szabályzat megváltozott. Javítsa a szerkesztőt vagy a bővítményt, és tegye vissza az időzítőt.

A NetworkManager forrása a tulajdonságot az IP-címzés sikerének késleltetéseként definiálja egy átjáróválaszig vagy az időtúllépésig, nulla alapértékkel, és a kapcsolatbeállítás definíciója az a hivatkozás, amelyet el kell olvasni, mielőtt bármilyen másodkézből leírt viselkedésre támaszkodna.