Qué espera realmente gateway-ping-timeout en NetworkManager

Usted encuentra connection.gateway-ping-timeout en un hilo sobre un portátil que arranca antes de que la red sea utilizable, lo sube y algo cambia. Si el cambio ayudó por el motivo que usted cree es una pregunta aparte. La respuesta empieza por lo que la activación hace realmente mientras ese temporizador corre, y por el hecho de que la espera tiene dos finales posibles.

Siga una conexión desde la línea de comandos y la semántica se vuelve concreta.

Siga una activación

Empiece mirando la conexión guardada en lugar de un valor predeterminado global, porque esto es una propiedad por conexión. Añada --show-secrets solo si realmente lo necesita; el ajuste en sí no es un secreto.

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

Con la propiedad en cero, que es el valor predeterminado documentado, la activación continúa en cuanto termina el direccionamiento. Póngala en un valor positivo y la activación de la configuración IP espera hasta que llegue una respuesta de la puerta de enlace o caduque el tiempo de espera.

Después baje y suba la conexión mientras observa el flujo de eventos. El orden que ve es la propiedad haciendo su trabajo: estado del dispositivo, direccionamiento, la espera y por último el estado activado contra el que suelen ordenarse los servicios dependientes.

La espera tiene dos finales

Ambos finales importan, y la mayoría de la gente solo recuerda uno. Una respuesta de la puerta de enlace termina la espera antes de tiempo, y el tiempo de espera también la termina, haya respondido algo o no. La propiedad no exige un ping correcto antes de que la activación pueda completarse.

Esa sola frase aclara mucha confusión sobre portátiles en hoteles y centros de congresos, donde un portal cautivo a menudo rechaza ICMP hasta que usted inicia sesión. La conexión se activa igualmente después de que caduque el tiempo de espera; simplemente lo hace más tarde de lo necesario, y cada servicio ordenado después de la conexión espera con ella.

Tampoco es una comprobación de vitalidad. Nada en la descripción empieza a hacer ping a una puerta de enlace después de que la conexión esté activa, y nada desconecta un perfil activo porque un ping posterior falle. Si necesita detección de pérdidas, eso corresponde al protocolo o al dueño del túnel, no a una propiedad que se ejecutó una vez durante la activación.

Dos objetos, un ajuste

El perfil base por cable y un perfil VPN son objetos de configuración separados, y poner la propiedad en uno no afecta al otro. Un perfil VPN que nombra una conexión base no hereda ninguno de sus ajustes de activación, y por eso el valor que cambió puede parecer que no tiene efecto sobre lo que usted observaba.

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

Lea los UUID en lugar de los nombres. Los nombres se duplican tras una reinstalación o un perfil restaurado, y dos conexiones con el mismo nombre visible le llevarán a editar el archivo equivocado mientras la real queda sin cambios.

La versión instalada de NetworkManager también importa. El comportamiento del complemento y cómo un tipo de conexión asigna esta propiedad a sus propios pasos de activación varían, así que pruebe en la versión que despliega en lugar de suponer que un artículo que encontró se aplica sin cambios.

Qué no puede certificar la espera

Aquí está la parte que cuesta más tiempo. Una respuesta del enrutador local demuestra que un host respondió un eco ICMP durante la activación. No demuestra que se resuelva un extremo de VPN, que se acepte la identidad del cliente, que se hayan instalado rutas privadas, que el resolutor de la oficina responda o que la aplicación que le importa vaya a funcionar.

Esas son dependencias separadas con pruebas separadas. Una puerta de enlace puede responder mientras DNS falla, y una puerta de enlace puede descartar ICMP en silencio por política mientras todas las rutas de aplicación funcionan. Por eso condicionar todo a esta propiedad es una conjetura sobre qué capa llega tarde, no una medición de ella.

Si espera un servicio dependiente, nombre qué necesita. Una dirección asignada la responde el direccionamiento. Un túnel lo responde el estado propio del túnel. Un nombre privado lo responde una consulta. Una aplicación la responde la aplicación, y ninguna de esas respuestas viene de un temporizador que lleva el nombre de la puerta de enlace.

Si lo cambia, escriba por qué

Registre el valor anterior y el motivo antes de un cambio aprobado, y luego póngalo en la conexión concreta en lugar de en todas partes. Una espera más larga desplaza el momento de activación de todo lo ordenado después de esa conexión, lo que puede hacer que un sistema lento parezca bien y uno rápido parezca roto.

Una trampa histórica merece mención: un valor como este a veces se cambia para que un editor más antiguo acepte un perfil. Si esa es la historia real, tiene dos sucesos, no uno. El editor guardó y una política de red viva cambió. Arregle el editor o el complemento y devuelva el temporizador.

El código fuente de NetworkManager define la propiedad como un retraso del éxito del direccionamiento IP hasta una respuesta de la puerta de enlace o el tiempo de espera, con un valor predeterminado de cero, y la definición del ajuste de conexión es la referencia que hay que leer antes de confiar en cualquier comportamiento descrito de segunda mano.