Waar gateway-ping-timeout in NetworkManager echt op wacht

Je vindt connection.gateway-ping-timeout in een thread over een laptop die opstart voordat het netwerk bruikbaar is, je verhoogt hem, en er verandert iets. Of de wijziging hielp om de reden die je denkt, is een aparte vraag. Het antwoord begint bij wat de activering feitelijk doet terwijl die timer loopt, en bij het feit dat de wachttijd twee mogelijke aflopen heeft.

Volg één verbinding vanaf de opdrachtregel en de semantiek wordt concreet.

Eén activering volgen

Begin bij de opgeslagen verbinding en niet bij een globale standaard, want dit is een eigenschap per verbinding. Voeg --show-secrets alleen toe als je het echt nodig hebt; de instelling zelf is geen geheim.

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

Staat de eigenschap op nul, de gedocumenteerde standaard, dan gaat de activering verder zodra de adressering klaar is. Zet je hem op een positieve waarde, dan wacht de activering van de IP-configuratie tot er een antwoord van de gateway komt of de time-out verloopt.

Breng de verbinding dan omlaag en weer omhoog terwijl je de gebeurtenissenstroom volgt. De volgorde die je ziet, is de instelling aan het werk: apparaatstatus, adressering, de wachttijd en ten slotte de geactiveerde status waarop afhankelijke diensten meestal worden geordend.

De wachttijd heeft twee aflopen

Beide aflopen tellen, en de meeste mensen onthouden er maar één. Een antwoord van de gateway beëindigt de wachttijd vroeg, en de time-out beëindigt hem ook, of er nu iets antwoordde of niet. De eigenschap vereist geen geslaagde ping voordat de activering kan voltooien.

Die ene zin ruimt veel verwarring op over laptops in hotels en conferentiecentra, waar een captive portal ICMP vaak weigert tot je inlogt. De verbinding activeert nog steeds nadat de time-out verloopt; hij doet dat alleen later dan nodig, en elke dienst die na de verbinding is geordend, wacht mee.

Het is ook geen levendigheidscontrole. Niets in de beschrijving begint een gateway te pingen nadat de verbinding omhoog is, en niets verbreekt een actief profiel omdat een latere ping mislukt. Heb je verliesdetectie nodig, dan hoort dat bij het protocol of de tunneleigenaar, niet bij een eigenschap die één keer tijdens de activering liep.

Twee objecten, één instelling

Het bekabelde basisprofiel en een VPN-profiel zijn aparte configuratieobjecten, en de eigenschap op het ene zetten beïnvloedt het andere niet. Een VPN-profiel dat een basisverbinding noemt, erft geen van zijn activeringsinstellingen, waardoor de waarde die je wijzigde geen effect lijkt te hebben op wat je bekeek.

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

Lees de UUID's en niet de namen. Namen raken gedupliceerd na een herinstallatie of een hersteld profiel, en twee verbindingen met dezelfde zichtbare naam laten je het verkeerde bestand bewerken terwijl het echte ongewijzigd blijft.

De geïnstalleerde NetworkManager-versie maakt ook uit. Plugingedrag en hoe een verbindingstype deze eigenschap op zijn eigen activeringsstappen afbeeldt, verschillen, dus test op de versie die je uitrolt in plaats van aan te nemen dat een gevonden bericht ongewijzigd geldt.

Wat de wachttijd niet kan bevestigen

Hier is het deel dat de meeste tijd kost. Een antwoord van de lokale router bewijst dat één host één ICMP-echo beantwoordde tijdens de activering. Het bewijst niet dat een VPN-eindpunt oplost, dat de identiteit van de client wordt aanvaard, dat privéroutes zijn geïnstalleerd, dat de resolver van het kantoor antwoordt, of dat de toepassing die je belangrijk vindt, zal werken.

Dat zijn aparte afhankelijkheden met apart bewijs. Een gateway kan antwoorden terwijl DNS faalt, en een gateway kan ICMP stilzwijgend laten vallen volgens beleid terwijl elk toepassingspad werkt. Op deze eigenschap gaten is daarom een gok over welke laag te laat is, geen meting ervan.

Wacht je op een afhankelijke dienst, benoem dan wat die nodig heeft. Een toegewezen adres wordt beantwoord door de adressering. Een tunnel wordt beantwoord door de eigen status van de tunnel. Een privénaam wordt beantwoord door een query. Een toepassing wordt beantwoord door de toepassing, en geen van die antwoorden komt van een timer die naar de gateway is vernoemd.

Als je het wijzigt, schrijf op waarom

Leg de vorige waarde en de reden vast vóór een goedgekeurde wijziging, en zet hem dan op de specifieke verbinding in plaats van overal. Een langere wachttijd verschuift de activeringstijd voor alles wat na die verbinding is geordend, wat een traag systeem er goed uit kan laten zien en een snel systeem kapot.

Eén historische valkuil is het noemen waard: zo'n waarde wordt soms gewijzigd om een oudere editor een profiel te laten accepteren. Als dat het echte verhaal is, heb je twee gebeurtenissen, niet één. De editor sloeg op, en een levend netwerkbeleid veranderde. Repareer de editor of de plugin en zet de timer terug.

De NetworkManager-bron definieert de eigenschap als een vertraging van succesvolle IP-adressering tot een gateway-antwoord of de time-out, met een standaard van nul, en de definitie van de verbindingsinstelling is de referentie die je leest voordat je vertrouwt op gedrag dat van horen zeggen komt.