Resultados ímpares do ping

3

Quando executo isso em uma caixa do Ubuntu:

sudo ping google.com -c 25  -l 25

Eu recebo cerca de 1 linha de volta a cada 2 segundos, apesar do fato de que deveria (se eu estiver lendo as coisas corretamente) enviar todos os 25 pacotes no get-go. Por estranho que pareça, estou recebendo tempos de ping de:

--- google.com ping statistics ---
25 packets transmitted, 24 received, 4% packet loss, time 0ms
rtt min/avg/max/mdev = 23.370/28.067/32.902/2.895 ms, pipe 24

Além disso, se eu quiser sair mais cedo, preciso dar um soco em ctrl-C uma vez para cada pacote. Alguém tem alguma idéia do que poderia estar causando isso?

    
por BCS 26.04.2011 / 06:28

2 respostas

5

Se você pingar via IP, ao contrário do hostname, você receberá o comportamento esperado.

Ainda estou investigando para descobrir a razão de ser esse o caso.

# find IP address of host
$ host -t a google.com
google.com has address 74.125.225.17
google.com has address 74.125.225.19
google.com has address 74.125.225.20
google.com has address 74.125.225.18
google.com has address 74.125.225.16

# pick an IP and ping it, all output is displayed at once
$ sudo ping 74.125.225.17 -c 25 -l 25
PING 74.125.225.17 (74.125.225.17) 56(84) bytes of data.
64 bytes from 74.125.225.17: icmp_seq=1 ttl=55 time=29.7 ms
64 bytes from 74.125.225.17: icmp_seq=2 ttl=55 time=30.4 ms
64 bytes from 74.125.225.17: icmp_seq=3 ttl=55 time=40.0 ms
64 bytes from 74.125.225.17: icmp_seq=4 ttl=55 time=40.4 ms
64 bytes from 74.125.225.17: icmp_seq=7 ttl=55 time=50.1 ms
64 bytes from 74.125.225.17: icmp_seq=5 ttl=55 time=50.4 ms
64 bytes from 74.125.225.17: icmp_seq=6 ttl=55 time=51.4 ms
64 bytes from 74.125.225.17: icmp_seq=8 ttl=55 time=52.4 ms
64 bytes from 74.125.225.17: icmp_seq=9 ttl=55 time=55.4 ms
64 bytes from 74.125.225.17: icmp_seq=10 ttl=55 time=56.4 ms
64 bytes from 74.125.225.17: icmp_seq=11 ttl=55 time=57.3 ms
64 bytes from 74.125.225.17: icmp_seq=13 ttl=55 time=58.3 ms
64 bytes from 74.125.225.17: icmp_seq=12 ttl=55 time=59.3 ms
64 bytes from 74.125.225.17: icmp_seq=14 ttl=55 time=60.3 ms
64 bytes from 74.125.225.17: icmp_seq=15 ttl=55 time=61.9 ms
64 bytes from 74.125.225.17: icmp_seq=16 ttl=55 time=62.3 ms
64 bytes from 74.125.225.17: icmp_seq=17 ttl=55 time=63.2 ms
64 bytes from 74.125.225.17: icmp_seq=18 ttl=55 time=64.2 ms
64 bytes from 74.125.225.17: icmp_seq=19 ttl=55 time=68.9 ms
64 bytes from 74.125.225.17: icmp_seq=20 ttl=55 time=69.2 ms
64 bytes from 74.125.225.17: icmp_seq=21 ttl=55 time=70.2 ms
64 bytes from 74.125.225.17: icmp_seq=22 ttl=55 time=75.9 ms
64 bytes from 74.125.225.17: icmp_seq=23 ttl=55 time=76.2 ms
64 bytes from 74.125.225.17: icmp_seq=24 ttl=55 time=77.2 ms
64 bytes from 74.125.225.17: icmp_seq=25 ttl=55 time=78.1 ms

UPDATE

Depois de executar o ping pela strace, descobri que ele estava ficando preso na resolução de nomes (sem surpresa). No entanto, a coisa que chamou minha atenção foi avahi-daemon . Este serviço implementa a arquitetura Zeroconf da Apple (também conhecida como "Rendezvous" ou "Bonjour"). Em outras palavras, funcionalidade eu não preciso.

Depois de parar o avahi-daemon, o comportamento do ping voltou ao normal.

# sudo /etc/init.d/avahi-daemon stop

Desativando-o durante a inicialização pode ser realizado com:

# sudo update-rc.d -f avahi-daemon

Outra solução é simplesmente usar o -n flag com ping. O desligamento é feito com pesquisas DNS reversas realizadas durante o processamento das respostas.

    
por 26.04.2011 / 09:42
1

Se você fizer um tcpdump enquanto faz seu ping, provavelmente verá que ele está pausando na pesquisa de mapeamento reverso ... isto é: quando ele procura o mapeamento DNS de IP para nome.

Eu acho que o avahi-daemon está sendo consultado em algum lugar na cadeia quando os pacotes voltam. O -25 só se preocupa com os pacotes de saída ... ping ainda vai fazer o seu trabalho e procurar todos os nomes, se você pré-carregar ou não. :)

    
por 26.04.2011 / 21:55