Che cosa aspetta davvero gateway-ping-timeout in NetworkManager

Trovi connection.gateway-ping-timeout in un thread su un portatile che si avvia prima che la rete sia utilizzabile, lo alzi, e qualcosa cambia. Se il cambiamento abbia aiutato per il motivo che pensi è una domanda separata. La risposta parte da ciò che l'attivazione sta effettivamente facendo mentre quel timer gira, e dal fatto che l'attesa ha due possibili finali.

Segui una connessione dalla riga di comando e la semantica diventa concreta.

Segui un'attivazione

Parti dalla connessione salvata invece che da un valore predefinito globale, perché questa è una proprietà per connessione. Aggiungi --show-secrets solo se ti serve davvero; l'impostazione in sé non è un segreto.

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

Con la proprietà a zero, che è il valore predefinito documentato, l'attivazione prosegue appena l'indirizzamento è completato. Impostala a un valore positivo e l'attivazione della configurazione IP attende finché non arriva una risposta dal gateway o non scade il timeout.

Poi abbassa e rialza la connessione osservando il flusso di eventi. L'ordine che vedi è l'impostazione al lavoro: stato del dispositivo, indirizzamento, l'attesa e infine lo stato attivato su cui di solito si ordinano i servizi dipendenti.

L'attesa ha due finali

Entrambi i finali contano, e la maggior parte delle persone ne ricorda solo uno. Una risposta dal gateway chiude l'attesa prima, e anche il timeout la chiude, che qualcosa abbia risposto o no. La proprietà non richiede un ping riuscito prima che l'attivazione possa completarsi.

Quella singola frase chiarisce molta confusione sui portatili negli hotel e nei centri congressi, dove un captive portal spesso rifiuta ICMP finché non accedi. La connessione si attiva comunque dopo la scadenza del timeout; semplicemente lo fa più tardi del necessario, e ogni servizio ordinato dopo la connessione aspetta con lei.

Non è nemmeno un controllo di vitalità. Nulla nella descrizione inizia a fare ping a un gateway dopo che la connessione è attiva, e nulla disconnette un profilo attivo perché un ping successivo fallisce. Se ti serve il rilevamento delle perdite, appartiene al proprietario del protocollo o del tunnel, non a una proprietà che è stata eseguita una volta durante l'attivazione.

Due oggetti, un'impostazione

Il profilo base cablato e un profilo VPN sono oggetti di configurazione separati, e impostare la proprietà su uno non influisce sull'altro. Un profilo VPN che nomina una connessione base non eredita nessuna delle sue impostazioni di attivazione, ed è per questo che il valore che hai cambiato può sembrare senza effetto su ciò che stavi osservando.

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

Leggi gli UUID invece dei nomi. I nomi si duplicano dopo una reinstallazione o un profilo ripristinato, e due connessioni con lo stesso nome visibile ti faranno modificare il file sbagliato mentre quella reale resta invariata.

Anche la versione installata di NetworkManager conta. Il comportamento del plugin e il modo in cui un tipo di connessione mappa questa proprietà sui propri passaggi di attivazione variano, quindi prova sulla versione che distribuisci invece di dare per scontato che un articolo che hai trovato valga senza modifiche.

Ciò che l'attesa non può certificare

Ecco la parte che costa più tempo. Una risposta dal router locale dimostra che un host ha risposto a un echo ICMP durante l'attivazione. Non dimostra che un endpoint VPN si risolva, che l'identità del client sia accettata, che siano state installate rotte private, che il resolver dell'ufficio risponda o che l'applicazione che ti interessa funzioni.

Quelle sono dipendenze separate con prove separate. Un gateway può rispondere mentre il DNS fallisce, e un gateway può scartare ICMP in silenzio per politica mentre tutti i percorsi dell'applicazione funzionano. Quindi usare questa proprietà come cancello è un'ipotesi su quale livello è in ritardo, non una sua misura.

Se stai aspettando un servizio dipendente, nomina ciò che gli serve. Un indirizzo assegnato riceve risposta dall'indirizzamento. Un tunnel riceve risposta dallo stato del tunnel stesso. Un nome privato riceve risposta da una query. Un'applicazione riceve risposta dall'applicazione, e nessuna di queste risposte viene da un timer che è stato chiamato come il gateway.

Se lo cambi, scrivi perché

Registra il valore precedente e il motivo prima di una modifica approvata, poi impostalo sulla connessione specifica invece che ovunque. Un'attesa più lunga sposta i tempi di attivazione per tutto ciò che è ordinato dopo quella connessione, il che può far sembrare a posto un sistema lento e rotto uno veloce.

Vale la pena nominare una trappola storica: un valore come questo a volte viene cambiato per far accettare un profilo a un editor più vecchio. Se è questa la storia vera, hai due eventi, non uno. L'editor ha salvato, e una politica di rete attiva è cambiata. Sistema l'editor o il plugin e rimetti il timer.

Il codice sorgente di NetworkManager definisce la proprietà come un ritardo del successo dell'indirizzamento IP fino a una risposta del gateway o al timeout, con un valore predefinito di zero, e la definizione dell'impostazione della connessione è il riferimento da leggere prima di affidarti a qualsiasi comportamento descritto di seconda mano.