Worauf gateway-ping-timeout in NetworkManager wirklich wartet

Sie finden connection.gateway-ping-timeout in einem Thread über ein Notebook, das hochfährt, bevor das Netzwerk nutzbar ist, Sie erhöhen ihn, und etwas ändert sich. Ob die Änderung aus dem Grund geholfen hat, den Sie annehmen, ist eine separate Frage. Die Antwort beginnt damit, was die Aktivierung tatsächlich tut, während dieser Timer läuft, und mit der Tatsache, dass das Warten zwei mögliche Enden hat.

Verfolgen Sie eine Verbindung von der Kommandozeile aus, und die Semantik wird konkret.

Eine Aktivierung verfolgen

Beginnen Sie mit der gespeicherten Verbindung statt mit einem globalen Standardwert, denn dies ist eine Eigenschaft pro Verbindung. Fügen Sie --show-secrets nur hinzu, wenn Sie es wirklich brauchen; die Einstellung selbst ist kein Geheimnis.

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

Steht die Eigenschaft auf null, dem dokumentierten Standard, läuft die Aktivierung weiter, sobald die Adressierung abgeschlossen ist. Setzen Sie sie auf einen positiven Wert, wartet die Aktivierung der IP-Konfiguration, bis entweder eine Antwort vom Gateway eintrifft oder das Timeout abläuft.

Bringen Sie die Verbindung dann herunter und wieder hoch, während Sie den Ereignisstrom beobachten. Die Reihenfolge, die Sie sehen, ist die Einstellung bei der Arbeit: Gerätezustand, Adressierung, das Warten und schließlich der aktivierte Zustand, gegen den abhängige Dienste üblicherweise geordnet werden.

Das Warten hat zwei Enden

Beide Enden zählen, und die meisten Menschen erinnern sich nur an eines. Eine Antwort vom Gateway beendet das Warten vorzeitig, und das Timeout beendet es ebenfalls, ob etwas geantwortet hat oder nicht. Die Eigenschaft verlangt keinen erfolgreichen Ping, bevor die Aktivierung abgeschlossen werden kann.

Dieser eine Satz räumt viel Verwirrung über Notebooks in Hotels und Konferenzzentren aus, wo ein Captive Portal ICMP oft ablehnt, bis man sich anmeldet. Die Verbindung wird auch nach Ablauf des Timeouts aktiviert; sie tut es nur später als nötig, und jeder Dienst, der nach der Verbindung geordnet ist, wartet mit.

Es ist auch keine Lebendigkeitsprüfung. Nichts in der Beschreibung beginnt, ein Gateway anzupingen, nachdem die Verbindung steht, und nichts trennt ein aktives Profil, weil ein späterer Ping fehlschlägt. Wenn Sie Verlusterkennung brauchen, gehört das dem Protokoll oder dem Tunneleigentümer, nicht einer Eigenschaft, die einmal während der Aktivierung lief.

Zwei Objekte, eine Einstellung

Das kabelgebundene Basisprofil und ein VPN-Profil sind getrennte Konfigurationsobjekte, und die Eigenschaft am einen zu setzen, beeinflusst das andere nicht. Ein VPN-Profil, das eine Basisverbindung nennt, erbt keine ihrer Aktivierungseinstellungen, weshalb der geänderte Wert scheinbar keine Wirkung auf das hat, was Sie beobachtet haben.

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

Lesen Sie die UUIDs statt der Namen. Namen werden nach einer Neuinstallation oder einem wiederhergestellten Profil doppelt vergeben, und zwei Verbindungen mit demselben sichtbaren Namen lassen Sie die falsche Datei bearbeiten, während die echte unverändert bleibt.

Auch die installierte NetworkManager-Version zählt. Das Verhalten der Plugins und die Art, wie ein Verbindungstyp diese Eigenschaft auf seine eigenen Aktivierungsschritte abbildet, unterscheiden sich, testen Sie also auf der Version, die Sie ausrollen, statt anzunehmen, ein gefundener Beitrag gelte unverändert.

Was das Warten nicht bestätigen kann

Hier ist der Teil, der die meiste Zeit kostet. Eine Antwort des lokalen Routers beweist, dass ein Host während der Aktivierung ein ICMP-Echo beantwortet hat. Sie beweist nicht, dass ein VPN-Endpunkt aufgelöst wird, dass die Identität des Clients akzeptiert wird, dass private Routen installiert wurden, dass der Resolver im Büro antwortet oder dass die Anwendung, die Ihnen wichtig ist, funktionieren wird.

Das sind getrennte Abhängigkeiten mit getrennten Belegen. Ein Gateway kann antworten, während DNS ausfällt, und ein Gateway kann ICMP per Richtlinie stillschweigend verwerfen, während jeder Anwendungspfad funktioniert. Sich auf diese Eigenschaft zu verlassen ist daher eine Vermutung darüber, welche Schicht zu spät ist, keine Messung davon.

Wenn Sie auf einen abhängigen Dienst warten, benennen Sie, was er braucht. Eine zugewiesene Adresse wird durch die Adressierung beantwortet. Ein Tunnel wird durch den eigenen Zustand des Tunnels beantwortet. Ein privater Name wird durch eine Abfrage beantwortet. Eine Anwendung wird durch die Anwendung beantwortet, und keine dieser Antworten kommt von einem Timer, der nach dem Gateway benannt wurde.

Wenn Sie es ändern, schreiben Sie auf, warum

Halten Sie den vorherigen Wert und den Grund vor einer genehmigten Änderung fest und setzen Sie ihn dann auf die konkrete Verbindung statt überall. Ein längeres Warten verschiebt den Aktivierungszeitpunkt für alles, was nach dieser Verbindung geordnet ist, was ein langsames System gut und ein schnelles kaputt aussehen lassen kann.

Eine historische Falle ist es wert, benannt zu werden: Ein solcher Wert wird manchmal geändert, damit ein älterer Editor ein Profil akzeptiert. Wenn das die wahre Geschichte ist, haben Sie zwei Ereignisse, nicht eines. Der Editor speicherte, und eine lebende Netzwerkrichtlinie änderte sich. Reparieren Sie den Editor oder das Plugin und stellen Sie den Timer zurück.

Die NetworkManager-Quelle definiert die Eigenschaft als Verzögerung des Erfolgs der IP-Adressierung bis zu einer Gateway-Antwort oder dem Timeout, mit einem Standard von null, und die Definition der Verbindungseinstellung ist die Referenz, die Sie lesen sollten, bevor Sie sich auf ein aus zweiter Hand beschriebenes Verhalten verlassen.