O que gateway-ping-timeout realmente espera no NetworkManager

Você encontra connection.gateway-ping-timeout numa discussão sobre um portátil que sobe antes de a rede ficar utilizável, aumenta o valor e algo muda. Se a mudança ajudou pelo motivo que você pensa é outra pergunta. A resposta começa pelo que a ativação realmente faz enquanto esse temporizador corre, e pelo facto de a espera ter dois finais possíveis.

Acompanhe uma conexão pela linha de comando e a semântica fica concreta.

Acompanhar uma ativação

Comece pela conexão guardada e não por um padrão global, porque esta é uma propriedade por conexão. Acrescente --show-secrets só se realmente precisar; a definição em si não é segredo.

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

Com a propriedade em zero, que é o padrão documentado, a ativação segue assim que o endereçamento termina. Defina um valor positivo e a ativação da configuração IP espera até chegar uma resposta do gateway ou o tempo limite expirar.

Depois desligue e religue a conexão enquanto observa o fluxo de eventos. A ordem que você vê é a definição a fazer o seu trabalho: estado do dispositivo, endereçamento, a espera e por fim o estado ativado pelo qual os serviços dependentes costumam ser ordenados.

A espera tem dois finais

Os dois finais importam, e a maioria das pessoas só se lembra de um. Uma resposta do gateway termina a espera mais cedo, e o tempo limite também a termina, quer algo tenha respondido quer não. A propriedade não exige um ping bem-sucedido para a ativação concluir.

Essa única frase esclarece muita confusão sobre portáteis em hotéis e centros de conferências, onde um portal cativo costuma recusar ICMP até você entrar. A conexão ainda ativa depois que o tempo limite expira; apenas o faz mais tarde do que precisava, e cada serviço ordenado depois da conexão espera junto.

Também não é uma verificação de vivacidade. Nada na descrição começa a pingar um gateway depois de a conexão estar ativa, e nada desconecta um perfil ativo porque um ping posterior falhou. Se você precisa de deteção de perda, isso pertence ao protocolo ou ao dono do túnel, não a uma propriedade que correu uma vez durante a ativação.

Dois objetos, uma definição

O perfil base com fio e um perfil VPN são objetos de configuração separados, e definir a propriedade num não afeta o outro. Um perfil VPN que nomeia uma conexão base não herda nenhuma das suas definições de ativação, e é por isso que o valor que você mudou pode parecer não ter efeito sobre o que estava a observar.

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

Leia os UUID e não os nomes. Os nomes duplicam-se depois de uma reinstalação ou de um perfil restaurado, e duas conexões com o mesmo nome visível levam você a editar o ficheiro errado enquanto o verdadeiro fica inalterado.

A versão instalada do NetworkManager também importa. O comportamento do plugin e a forma como um tipo de conexão mapeia esta propriedade nos seus próprios passos de ativação variam, por isso teste na versão que você implementa em vez de assumir que um artigo que encontrou se aplica sem alterações.

O que a espera não pode certificar

Aqui está a parte que custa mais tempo. Uma resposta do router local prova que um host respondeu a um eco ICMP durante a ativação. Não prova que um endpoint VPN resolve, que a identidade do cliente é aceita, que rotas privadas foram instaladas, que o resolver do escritório responde, ou que a aplicação que lhe importa vai funcionar.

Essas são dependências separadas com evidências separadas. Um gateway pode responder enquanto o DNS falha, e um gateway pode descartar ICMP em silêncio por política enquanto todos os caminhos da aplicação funcionam. Condicionar a esta propriedade é, portanto, um palpite sobre qual camada está atrasada, não uma medição dela.

Se você está à espera de um serviço dependente, nomeie o que ele precisa. Um endereço atribuído é respondido pelo endereçamento. Um túnel é respondido pelo estado do próprio túnel. Um nome privado é respondido por uma consulta. Uma aplicação é respondida pela aplicação, e nenhuma dessas respostas vem de um temporizador com o nome do gateway.

Se você mudar, escreva porquê

Registe o valor anterior e o motivo antes de uma mudança aprovada, e depois defina-o na conexão específica em vez de em todo o lado. Uma espera mais longa desloca o momento de ativação de tudo o que é ordenado depois dessa conexão, o que pode fazer um sistema lento parecer bem e um rápido parecer avariado.

Vale a pena nomear uma armadilha histórica: um valor como este às vezes é alterado para que um editor antigo aceite um perfil. Se essa for a história real, você tem dois eventos, não um. O editor guardou, e uma política de rede ao vivo mudou. Corrija o editor ou o plugin e reponha o temporizador.

O código-fonte do NetworkManager define a propriedade como um atraso do sucesso do endereçamento IP até uma resposta do gateway ou o tempo limite, com padrão zero, e a definição da configuração de conexão é a referência a ler antes de confiar em qualquer comportamento descrito em segunda mão.