Por que meus resultados do comando ping (Windows) alternam entre “tempo limite” e “rede não está acessível”?

4

Meu Windows é em espanhol, então terei que colar as saídas do console nesse idioma (acho que traduzir sem conhecer os termos exatos usados nas versões em inglês pode dar resultados piores do que deixá-lo como aparece na tela).
Esse é o problema: quando pingando um IP inexistente de uma máquina WinXP-SP3 (instalação limpa do Windows, apenas formatada), às vezes recebo um resultado de "Tempo de espera" e às vezes uma mensagem "rede não é alcançável". Este é o resultado de:

ping 192.168.210.1
Haciendo ping a 192.168.210.1 con 32 bytes de datos:
Tiempo de espera agotado para esta solicitud.
Respuesta desde 80.58.67.86: Red de destino inaccesible.
Respuesta desde 80.58.67.86: Red de destino inaccesible.
Tiempo de espera agotado para esta solicitud.
Estadísticas de ping para 192.168.210.1:
    Paquetes: enviados = 4, recibidos = 2, perdidos = 2
    (50% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 0ms, Máximo = 0ms, Media = 0ms

192.168.210.1 não existe na rede.
Cliente DHCP está habilitado e o computador é atribuído a essas configurações de rede pelo roteador. Meu IP: 192.168.11.2
Máscara de rede: 255.255.255.0
Gateway: 192.168.11.1
DNS: 80.58.0.33/194.224.52.36

Esta é a saída do "comando route print":

===========================================================================
Rutas activas:
Destino de red        Máscara de red   Puerta de acceso   Interfaz  Métrica
          0.0.0.0          0.0.0.0     192.168.11.1    192.168.11.2       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.11.0    255.255.255.0     192.168.11.2    192.168.11.2       20
     192.168.11.2  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.11.255  255.255.255.255     192.168.11.2    192.168.11.2       20
        224.0.0.0        240.0.0.0     192.168.11.2    192.168.11.2       20
  255.255.255.255  255.255.255.255     192.168.11.2    192.168.11.2       1
  255.255.255.255  255.255.255.255     192.168.11.2               3       1
Puerta de enlace predeterminada:      192.168.11.1
===========================================================================
Rutas persistentes:
  ninguno

A saída de:

ping 1.1.1.1
Haciendo ping a 1.1.1.1 con 32 bytes de datos:
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Estadísticas de ping para 1.1.1.1:
    Paquetes: enviados = 4, recibidos = 0, perdidos = 4

1.1.1.1 não existe na rede.
e a saída de:

ping 10.1.1.1
Haciendo ping a 10.1.1.1 con 32 bytes de datos:
Respuesta desde 80.58.67.86: Red de destino inaccesible.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Respuesta desde 80.58.67.86: Red de destino inaccesible.
Estadísticas de ping para 10.1.1.1:
    Paquetes: enviados = 4, recibidos = 2, perdidos = 2
    (50% perdidos),

10.1.1.1 não existe na rede.
Eu posso fazer uma tradução aproximada do que você procura, se necessário.
Eu tenho outros computadores na mesma rede (WinXP-SP3 e Win7-SP1), e eles têm, também, esse problema.
Gateway (Roteador): Búfalo WHR-HP-GN (firmware oficial Buffalo, não DD-WRT).

Eu tenho algumas máquinas Linux (Debian / Kali) na minha rede, então testei as coisas:

ping 192.168.210.1
PING 192.168.210.1 (192.168.210.1) 56(84) bytes of data.
From 80.58.67.86 icmp_seq=1 Packet filtered
From 80.58.67.86 icmp_seq=2 Packet filtered
From 80.58.67.86 icmp_seq=3 Packet filtered
From 80.58.67.86 icmp_seq=4 Packet filtered

para o 1.1.1.1 não existente:

ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
153 packets transmitted, 0 received, 100% packet loss, time 153215ms

(sem resposta depois de esperar alguns minutos).
e o não existente 10.1.1.1:

ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
From 80.58.67.86 icmp_seq=20 Packet filtered
From 80.58.67.86 icmp_seq=22 Packet filtered
From 80.58.67.86 icmp_seq=23 Packet filtered
From 80.58.67.86 icmp_seq=24 Packet filtered
From 80.58.67.86 icmp_seq=25 Packet filtered

O que está acontecendo aqui?

Estou colocando essa questão principalmente para fins de aprendizado, mas há outro motivo: quando todos os pings estão retornando "timeout", isso cria um valor % ERRORLEVEL% de 1, mas se houver alguém do tipo "Rede não está acessível", % ERRORLEVEL% vai para 0 (sem erro), e isso pode ser inapropriado para um script de shell (não podemos usar o ping para detectar, por exemplo, se a rede está inoperante devido à perda de contato com o gateway).

Atualização de 2017 a abril :

  • Por enquanto, o erro desapareceu , desculpe. Eu continuarei este tópico se ocorrer novamente. Obrigado a todos que colaboraram.
por Sopalajo de Arrierez 01.03.2014 / 13:34

2 respostas

1

Eu tentaria alterar o valor do tempo limite do ping nas caixas do Windows para ver se isso altera o comportamento.

ping -w 5000 192.168.201.1

Como esse não é apenas um IP inexistente, mas também uma sub-rede inexistente, ele é passado para o roteador e o roteador não sabe o que fazer com ele. Eu estou especulando que o firmware do roteador leva um tempo para responder com uma mensagem Destination Unreachable, em uma ordem similar ao timeout do ping, então às vezes o ping expira antes que a mensagem Destination Unreachable seja recebida.

Com relação ao problema% ERRORLEVEL%, você ainda pode usá-lo para detectar quando pings falharem no gateway. Se você estiver executando ping em 192.168.11.1 e seu roteador parar de responder, os pings subsequentes para esse endereço expirarão. Isso é diferente de pings para um endereço IP inexistente e arbitrário em sua sub-rede, pois o IP do gateway já está armazenado em sua tabela ARP.

No que espero ser uma nota não relacionada (caso contrário, não estou visualizando sua rede corretamente), parece estranho que seu roteador use seu endereço IP público dentro da LAN.

    
por 07.03.2014 / 20:13
0

1.1.1.1 é alocado ao APNIC para propósitos experimentais (principalmente para monitorar abusos como os acima, que o tornam inutilizável). Atualmente, ele acaba no Google, que não responde.

    
por 05.06.2014 / 11:14