Kva gateway-ping-timeout i NetworkManager eigentleg ventar på

Du finn connection.gateway-ping-timeout i ein tråd om ein berbar PC som startar før nettverket er brukbart, du aukar han, og noko endrar seg. Om endringa hjelpte av grunnen du trur, er eit eige spørsmål. Svaret byrjar med kva aktiveringa faktisk gjer medan timeren går, og med at ventinga har to moglege avslutningar.

Følg éi tilkopling frå kommandolinja, og semantikken blir konkret.

Følg éi aktivering

Start med den lagra tilkoplinga og ikkje ein global standard, fordi dette er ein eigenskap per tilkopling. Legg til --show-secrets berre viss du faktisk treng det; innstillinga sjølv er ikkje hemmeleg.

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

Med eigenskapen på null, som er den dokumenterte standarden, går aktiveringa vidare så snart adresseringa er fullført. Set du ein positiv verdi, ventar aktiveringa av IP-konfigurasjonen til eit svar kjem frå gatewayen eller tidsavbrotet går ut.

Ta så tilkoplinga ned og opp medan du ser på hendingsstraumen. Rekkjefølgja du ser, er innstillinga som gjer jobben sin: einingstilstand, adressering, ventinga og til slutt den aktiverte tilstanden som avhengige tenester vanlegvis blir ordna etter.

Ventinga har to avslutningar

Båe avslutningane tel, og dei fleste hugsar berre éin. Eit svar frå gatewayen avsluttar ventinga tidleg, og tidsavbrotet avsluttar ho òg, same om noko svara. Eigenskapen krev ikkje ein vellukka ping før aktiveringa kan fullførast.

Den eine setninga ryddar opp i mykje forvirring om berbare PC-ar på hotell og konferansestader, der ein captive portal ofte nektar ICMP til du loggar inn. Tilkoplinga blir likevel aktivert etter at tidsavbrotet går ut; ho gjer det berre seinare enn nødvendig, og kvar teneste som er ordna etter tilkoplinga, ventar med henne.

Det er heller ikkje ein levetidssjekk. Ingenting i skildringa byrjar å pinge ein gateway etter at tilkoplinga er oppe, og ingenting koplar frå ein aktiv profil fordi ein seinare ping feilar. Treng du tapsoppdaging, høyrer det til protokollen eller tunneleigaren, ikkje til ein eigenskap som køyrde éin gong under aktiveringa.

To objekt, éi innstilling

Den kabelbundne basisprofilen og ein VPN-profil er separate konfigurasjonsobjekt, og å setje eigenskapen på éin påverkar ikkje den andre. Ein VPN-profil som namngjev ei basistilkopling, arvar ingen av aktiveringsinnstillingane hennar, og difor kan verdien du endra, sjå ut til å ikkje ha nokon verknad på det du følgde med på.

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

Les UUID-ane og ikkje namna. Namn blir dupliserte etter ein ominstallasjon eller ein gjenoppretta profil, og to tilkoplingar med same synlege namn får deg til å redigere feil fil medan den ekte blir ståande uendra.

Den installerte NetworkManager-versjonen betyr òg noko. Utvidingsåtferd og korleis ein tilkoplings type mappar denne eigenskapen til sine eigne aktiveringstrinn varierer, så test på versjonen du rullar ut i staden for å anta at eit innlegg du fann gjeld uendra.

Kva ventinga ikkje kan stadfeste

Her er delen som kostar mest tid. Eit svar frå den lokale rutaren beviser at éin vert svara på éin ICMP-ekko under aktiveringa. Det beviser ikkje at eit VPN-endepunkt lèt seg slå opp, at identiteten til klienten blir godteken, at private ruter vart installerte, at namnetenaren på kontoret svarar, eller at programmet du bryr deg om, vil verke.

Det er separate avhengnader med separate bevis. Ein gateway kan svare medan DNS feilar, og ein gateway kan stille droppe ICMP etter policy medan alle programvegar verkar. Å setje ein føresetnad på denne eigenskapen er difor ei gissing om kva lag som er seint, ikkje ei måling av det.

Viss du ventar på ei avhengig teneste, nemn kva ho treng. Ei tildelt adresse blir svara av adresseringa. Ein tunnel blir svara av tilstanden til tunnelen sjølv. Eit privat namn blir svara av ein spørjing. Eit program blir svara av programmet, og ingen av desse svara kjem frå ein timer som vart kalla opp etter gatewayen.

Viss du endrar han, skriv ned kvifor

Noter den førre verdien og grunnen før ei godkjend endring, og set han så på den bestemte tilkoplinga i staden for overalt. Ei lengre venting forskyv aktiveringstidspunktet for alt som er ordna etter den tilkoplinga, noko som kan få eit tregt system til å sjå fint ut og eit raskt til å sjå øydelagt ut.

Ei historisk felle er verd å nemne: ein verdi som denne blir stundom endra for å få ein eldre editor til å godta ein profil. Viss det er den eigentlege historia, har du to hendingar, ikkje éi. Editoren lagra, og ein levande nettverkspolicy endra seg. Fiks editoren eller utvidinga og set timeren tilbake.

NetworkManager-kjelda definerer eigenskapen som ei forseinking av vellukka IP-adressering til eit gatewaysvar eller tidsavbrotet, med standardverdien null, og definisjonen av tilkoplingsinnstillinga er referansen du bør lese før du stolar på åtferd som er skildra på andre hand.