Hva gateway-ping-timeout egentlig venter på i NetworkManager

Du finner connection.gateway-ping-timeout i en tråd om en bærbar PC som starter før nettverket er brukbart, du øker den, og noe endrer seg. Om endringen hjalp av grunnen du tror, er et eget spørsmål. Svaret begynner med hva aktiveringen faktisk gjør mens timeren løper, og med at ventingen har to mulige avslutninger.

Følg én tilkobling fra kommandolinjen, og semantikken blir konkret.

Følg én aktivering

Start med den lagrede tilkoblingen og ikke en global standard, fordi dette er en egenskap per tilkobling. Legg til --show-secrets bare hvis du faktisk trenger det; innstillingen selv er ikke hemmelig.

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

Med egenskapen på null, som er den dokumenterte standarden, går aktiveringen videre så snart adresseringen er fullført. Setter du en positiv verdi, venter aktiveringen av IP-konfigurasjonen til et svar kommer fra gatewayen eller tidsavbruddet utløper.

Ta så tilkoblingen ned og opp mens du ser på hendelsesstrømmen. Rekkefølgen du ser, er innstillingen som gjør jobben sin: enhetstilstand, adressering, ventingen og til slutt den aktiverte tilstanden som avhengige tjenester vanligvis ordnes etter.

Ventingen har to avslutninger

Begge avslutningene betyr noe, og de fleste husker bare én. Et svar fra gatewayen avslutter ventingen tidlig, og tidsavbruddet avslutter den også, uansett om noe svarte. Egenskapen krever ikke en vellykket ping før aktiveringen kan fullføres.

Den ene setningen rydder opp i mye forvirring om bærbare PC-er på hoteller og konferansesteder, der en captive portal ofte nekter ICMP til du logger inn. Tilkoblingen aktiveres likevel etter at tidsavbruddet utløper; den gjør det bare senere enn nødvendig, og hver tjeneste som er ordnet etter tilkoblingen, venter med den.

Det er heller ikke en levetidssjekk. Ingenting i beskrivelsen begynner å pinge en gateway etter at tilkoblingen er oppe, og ingenting kobler fra en aktiv profil fordi en senere ping feiler. Trenger du tapsoppdagelse, hører det til protokollen eller tunneleieren, ikke til en egenskap som kjørte én gang under aktiveringen.

To objekter, én innstilling

Den kablede basisprofilen og en VPN-profil er separate konfigurasjonsobjekter, og å sette egenskapen på én påvirker ikke den andre. En VPN-profil som navngir en basistilkobling, arver ingen av aktiveringsinnstillingene dens, og derfor kan verdien du endret, se ut til å ikke ha noen virkning på det du fulgte med på.

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

Les UUID-ene og ikke navnene. Navn dupliseres etter en ominstallasjon eller en gjenopprettet profil, og to tilkoblinger med samme synlige navn får deg til å redigere feil fil mens den ekte blir stående uendret.

Den installerte NetworkManager-versjonen betyr også noe. Utvidelsesatferd og hvordan en tilkoblingstype mapper denne egenskapen til sine egne aktiveringstrinn varierer, så test på versjonen du ruller ut i stedet for å anta at et innlegg du fant gjelder uendret.

Hva ventingen ikke kan bekrefte

Her er delen som koster mest tid. Et svar fra den lokale ruteren beviser at én vert svarte på én ICMP-ekko under aktiveringen. Det beviser ikke at et VPN-endepunkt lar seg slå opp, at klientens identitet godtas, at private ruter ble installert, at kontorets navnetjener svarer, eller at programmet du bryr deg om, vil virke.

Det er separate avhengigheter med separate bevis. En gateway kan svare mens DNS feiler, og en gateway kan stille droppe ICMP etter policy mens alle programveier virker. Å sette en betingelse på denne egenskapen er derfor en gjetning om hvilket lag som er sent, ikke en måling av det.

Hvis du venter på en avhengig tjeneste, navngi hva den trenger. En tildelt adresse besvares av adresseringen. En tunnel besvares av tunnelens egen tilstand. Et privat navn besvares av en spørring. Et program besvares av programmet, og ingen av disse svarene kommer fra en timer som ble oppkalt etter gatewayen.

Hvis du endrer den, skriv ned hvorfor

Noter den forrige verdien og grunnen før en godkjent endring, og sett den så på den bestemte tilkoblingen i stedet for overalt. En lengre venting forskyver aktiveringstidspunktet for alt som er ordnet etter den tilkoblingen, noe som kan få et tregt system til å se fint ut og et raskt til å se ødelagt ut.

En historisk felle er verdt å nevne: en verdi som denne blir noen ganger endret for å få en eldre editor til å godta en profil. Hvis det er den egentlige historien, har du to hendelser, ikke én. Editoren lagret, og en levende nettverkspolicy endret seg. Fiks editoren eller utvidelsen og sett timeren tilbake.

NetworkManager-kilden definerer egenskapen som en forsinkelse av vellykket IP-adressering til et gatewaysvar eller tidsavbruddet, med standardverdien null, og definisjonen av tilkoblingsinnstillingen er referansen du bør lese før du stoler på atferd som er beskrevet på andre hånd.