O que gateway-ping-timeout espera realmente en NetworkManager

Atopas connection.gateway-ping-timeout nun fío sobre un portátil que arrinca antes de que a rede sexa usable, elévalo, e algo cambia. Se o cambio axudou pola razón que cres é unha cuestión aparte. A resposta comeza polo que a activación está a facer realmente mentres ese temporizador corre, e polo feito de que a espera ten dous finais posibles.

Segue unha conexión desde a liña de ordes e a semántica vólvese concreta.

Segue unha activación

Empeza mirando a conexión gardada en vez dun valor predeterminado global, porque esta é unha propiedade por conexión. Engade --show-secrets só se realmente o necesitas; a configuración en si non é un segredo.

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

Coa propiedade en cero, que é o valor predeterminado documentado, a activación continúa en canto remata o direccionamento. Ponlle un valor positivo e a activación da configuración IP espera ata que chegue unha resposta da pasarela ou ata que expire o tempo límite.

Despois baixa e sobe a conexión mentres observas o fluxo de eventos. A orde que ves é a configuración facendo o seu traballo: estado do dispositivo, direccionamento, a espera e, por último, o estado activado contra o que adoitan ordenarse os servizos dependentes.

A espera ten dous finais

Os dous finais importan, e a maioría da xente só lembra un. Unha resposta da pasarela remata a espera antes de tempo, e o tempo límite tamén a remata, responda algo ou non. A propiedade non esixe un ping correcto antes de que a activación poida completarse.

Esa única frase aclara moita confusión sobre portátiles en hoteis e recintos de conferencias, onde un portal cautivo adoita rexeitar ICMP ata que inicias sesión. A conexión actívase igualmente despois de que expire o tempo límite; simplemente faino máis tarde do necesario, e cada servizo ordenado despois da conexión espera con ela.

Tampouco é unha comprobación de vitalidade. Nada na descrición comeza a facer ping a unha pasarela despois de que a conexión estea activa, e nada desconecta un perfil activo porque un ping posterior falle. Se necesitas detección de perdas, iso pertence ao dono do protocolo ou do túnel, non a unha propiedade que se executou unha vez durante a activación.

Dous obxectos, unha configuración

O perfil base con cable e un perfil VPN son obxectos de configuración separados, e establecer a propiedade nun non afecta ao outro. Un perfil VPN que nomea unha conexión base non herda ningunha das súas configuracións de activación, e por iso o valor que cambiaches pode parecer que non ten efecto sobre o que estabas a vixiar.

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

Le os UUID en vez dos nomes. Os nomes duplícanse despois dunha reinstalación ou dun perfil restaurado, e dúas conexións co mesmo nome visible farán que edites o ficheiro incorrecto mentres a real queda sen cambios.

A versión de NetworkManager instalada tamén importa. O comportamento do complemento e o xeito en que un tipo de conexión mapea esta propiedade nos seus propios pasos de activación varían, así que proba na versión que despregas en vez de supor que un artigo que atopaches se aplica sen cambios.

O que a espera non pode certificar

Aquí está a parte que máis tempo custa. Unha resposta do router local demostra que unha máquina respondeu a un eco ICMP durante a activación. Non demostra que un extremo VPN resolva, que se acepte a identidade do cliente, que se instalasen rutas privadas, que responda o resolver da oficina, ou que funcione a aplicación que che importa.

Eses son dependencias separadas con evidencias separadas. Unha pasarela pode responder mentres DNS falla, e unha pasarela pode descartar ICMP silenciosamente por política mentres todos os camiños de aplicación funcionan. Polo tanto, condicionar a esta propiedade é unha conxectura sobre que capa vai tarde, non unha medición dela.

Se estás á espera dun servizo dependente, nomea o que necesita. Un enderezo asignado respóndese co direccionamento. Un túnel respóndese co estado propio do túnel. Un nome privado respóndese cunha consulta. Unha aplicación respóndese coa aplicación, e ningunha desas respostas vén dun temporizador que se chamou así pola pasarela.

Se o cambias, escribe por que

Rexistra o valor anterior e o motivo antes dun cambio aprobado, e despois establéceo na conexión concreta en vez de en todas. Unha espera máis longa despraza a temporalización da activación para todo o que se ordena despois desa conexión, o que pode facer que un sistema lento pareza correcto e un rápido pareza roto.

Vale a pena nomear unha trampa histórica: un valor coma este ás veces cámbiase para que un editor antigo acepte un perfil. Se esa é a historia real, tes dous acontecementos, non un. O editor gardou, e unha política de rede activa cambiou. Arranxa o editor ou o complemento e devolve o temporizador ao seu sitio.

O código fonte de NetworkManager define a propiedade como un atraso do éxito do direccionamento IP ata unha resposta da pasarela ou o tempo límite, cun valor predeterminado de cero, e a definición da configuración da conexión é a referencia que hai que ler antes de confiar en calquera comportamento descrito de segunda man.