Vad gateway-ping-timeout i NetworkManager egentligen väntar på

Du hittar connection.gateway-ping-timeout i en tråd om en bärbar dator som startar innan nätet är användbart, du höjer den, och något ändras. Om ändringen hjälpte av den anledning du tror är en separat fråga. Svaret börjar med vad aktiveringen faktiskt gör medan timern går, och med att väntan har två möjliga slut.

Följ en anslutning från kommandoraden och semantiken blir konkret.

Följ en aktivering

Börja med den sparade anslutningen och inte med en global standard, eftersom detta är en egenskap per anslutning. Lägg till --show-secrets bara om du verkligen behöver det; inställningen själv är ingen hemlighet.

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

Med egenskapen på noll, vilket är den dokumenterade standarden, går aktiveringen vidare så snart adresseringen är klar. Sätt ett positivt värde och aktiveringen av IP-konfigurationen väntar tills ett svar kommer från gatewayen eller tidsgränsen löper ut.

Ta sedan ner och upp anslutningen medan du tittar på händelseströmmen. Ordningen du ser är inställningen som gör sitt jobb: enhetsstatus, adressering, väntan och till sist det aktiverade tillstånd som beroende tjänster brukar ordnas efter.

Väntan har två slut

Båda sluten spelar roll, och de flesta minns bara ett. Ett svar från gatewayen avslutar väntan tidigt, och tidsgränsen avslutar den också, oavsett om något svarade. Egenskapen kräver ingen lyckad ping innan aktiveringen kan slutföras.

Den enda meningen reder ut en hel del förvirring kring bärbara datorer på hotell och konferensanläggningar, där en captive portal ofta nekar ICMP tills du loggar in. Anslutningen aktiveras ändå när tidsgränsen löper ut; den gör det bara senare än nödvändigt, och varje tjänst som ordnas efter anslutningen väntar med den.

Det är inte heller en livskontroll. Ingenting i beskrivningen börjar pinga en gateway efter att anslutningen är uppe, och ingenting kopplar bort en aktiv profil för att en senare ping misslyckas. Behöver du förlustdetektering hör det till protokollet eller tunnelejaren, inte till en egenskap som kördes en gång under aktiveringen.

Två objekt, en inställning

Den trådbundna basprofilen och en VPN-profil är separata konfigurationsobjekt, och att sätta egenskapen på den ena påverkar inte den andra. En VPN-profil som namnger en basanslutning ärver inga av dess aktiveringsinställningar, och därför kan värdet du ändrade verka sakna effekt på det du följde.

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

Läs UUID:n och inte namnen. Namn dupliceras efter en ominstallation eller en återställd profil, och två anslutningar med samma synliga namn får dig att redigera fel fil medan den riktiga står kvar oförändrad.

Den installerade NetworkManager-versionen spelar också roll. Pluginbeteende och hur en anslutningstyp mappar den här egenskapen till sina egna aktiveringssteg varierar, så testa på versionen du driftsätter i stället för att anta att ett inlägg du hittade gäller oförändrat.

Vad väntan inte kan intyga

Här är delen som kostar mest tid. Ett svar från den lokala routern bevisar att en värd svarade på ett ICMP-eko under aktiveringen. Det bevisar inte att en VPN-slutpunkt löses upp, att klientens identitet accepteras, att privata rutter installerades, att kontorets namnserver svarar, eller att programmet du bryr dig om kommer att fungera.

Det är separata beroenden med separata bevis. En gateway kan svara medan DNS misslyckas, och en gateway kan tyst släppa ICMP enligt policy medan alla programvägar fungerar. Att villkora på den här egenskapen är därför en gissning om vilket lager som är sent, inte en mätning av det.

Om du väntar på en beroende tjänst, namnge vad den behöver. En tilldelad adress besvaras av adresseringen. En tunnel besvaras av tunnelns eget tillstånd. Ett privat namn besvaras av en fråga. Ett program besvaras av programmet, och inget av dessa svar kommer från en timer som döpts efter gatewayen.

Om du ändrar den, skriv ner varför

Anteckna det tidigare värdet och skälet före en godkänd ändring, och sätt det sedan på den specifika anslutningen i stället för överallt. En längre väntan förskjuter aktiveringstiden för allt som ordnas efter den anslutningen, vilket kan få ett långsamt system att se bra ut och ett snabbt att se trasigt ut.

En historisk fälla är värd att nämna: ett sådant värde ändras ibland för att en äldre editor ska acceptera en profil. Om det är den riktiga historien har du två händelser, inte en. Editorn sparade, och en levande nätverkspolicy ändrades. Fixa editorn eller insticksprogrammet och sätt tillbaka timern.

NetworkManager-källan definierar egenskapen som en fördröjning av lyckad IP-adressering till ett gatewaysvar eller tidsgränsen, med standardvärdet noll, och definitionen av anslutningsinställningen är referensen du bör läsa innan du litar på beteende som beskrivits på andra hand.