Ping não funciona como esperado

Question

Esta é uma espécie de acompanhamento para esta pergunta.

Meu objetivo no final é usar meu Raspberry Pi 1 Model B para registrar quando a conexão com a Internet cair, e por quanto tempo.

Eu tentei fazer isso com o seguinte comando:

ping 8.8.8.8 |  while read line; do echo "$(date): $line"; done | grep --line-buffered time= | tee -a googleping

O comando acima funciona em um servidor Ubuntu 15.10 e também no meu MacBook Air com OS X 10.11.2. Então eu pensei que poderia usar o mesmo no Pi. Mas o primeiro erro apareceu.

$ ping 8.8.8.8

ping: icmp open socket: Operation not permitted

Para contornar isso, comecei a pingar como superusuário:

$ sudo ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=12.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=12.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=13.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=12.6 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 12.640/12.787/13.002/0.171 ms

Agora você acha que isso resolve o meu problema, mas não, depois disso, há outro problema que notei. O comando ping no Pi não produz tempos limite de solicitação. Então, quando um pacote é expirado, o Pi apenas o reenvia onde eu esperaria uma mensagem como essa:

Request timeout for icmp_seq 39

Mas o que eu recebo é simplesmente nada, aparentemente apenas reenvia o pacote até que ele receba uma resposta, mas os pacotes perdidos aparecem no resumo no final:

--- 8.8.8.8 ping statistics ---
168 packets transmitted, 131 received, 22% packet loss, time 167191ms
rtt min/avg/max/mdev = 12.082/13.099/32.888/2.322 ms

A última saída antes do resumo é a seguinte:

64 bytes from 8.8.8.8: icmp_seq=150 ttl=58 time=12.5 ms

O que mostra que apenas 151 icmp_sequences diferentes foram enviados, e os descartados apenas reenviáram repetidamente.

Eu também devo adicionar, que eu pingue meu roteador local 192.168.2.1 além do google 8.8.8.8 para ver se é a conexão com o roteador, ou realmente a conexão com o google.

Os seguintes resultados resultam no mesmo resultado em ambos os sistemas:

$ ping -V

ping utility, iputils-s20121221

Depois de olhar em volta, encontrei uma opção na página de manual para ping no Pi que faz o que eu quero:

$ man ping

[...]
-O     Report  outstanding  ICMP  ECHO  reply  before  sending next packet.
       This is useful together with the timestamp -D to log output to a 
       diagnostic  file  and  search  for missing answers.
[...]

Isso produz a seguinte saída se um pacote for muito lento:

no answer yet for icmp_seq=499

Mas, se meu entendimento estiver correto, isso é diferente na maneira como o comando ping no Ubuntu só envia a mensagem se a resposta não for recebida antes do tempo limite, mesmo que outro pacote ping tenha sido enviado antes da resposta recebida. O comando ping no meu Pi imprime a mensagem também quando a resposta será reativada após a mensagem ser recebida.

Então, por que isso é diferente em um Pi do que em um servidor Ubuntu? Como posso alcançar meu objetivo?

Pergunta também publicada em raspberrypi.stackexchange.com .

    

Answer 1

Primeiro de tudo, o seguinte comando

 sudo chmod u+s 'which ping'

fará o ping funcionar também para um usuário não-su.

Em segundo lugar, você pode curar seu problema com a seguinte opção,

ping -c 1 -W 1 192.168.0.1

A primeira opção envia um único pacote, o segundo estabelece um período de tempo limite além do qual um pacote é declarado ausente e uma mensagem de erro é impressa. Por exemplo,

$ ping -c1 www.nytimes.com
  PING www.gtm.nytimes.com (170.149.161.130) 56(84) bytes of data.
  ^C
  --- www.gtm.nytimes.com ping statistics ---
  1 packets transmitted, 0 received, 100% packet loss, time 0ms

 $ ping -c1 -W 1 www.nytimes.com
   PING www.gtm.nytimes.com (170.149.161.130) 56(84) bytes of data.

   --- www.gtm.nytimes.com ping statistics ---
   1 packets transmitted, 0 received, 100% packet loss, time 0ms

Como você pode ver, no primeiro caso (sem a opção -W 1 ) ping estava esperando por uma resposta e somente minha Ctrl + C parou o aguarde, sem saída produzida. Mas no segundo caso, com -W 1 (= Aguardar 1 segundo e desistir), uma mensagem de erro foi prontamente produzida.

Mas, em terceiro lugar, sugiro que você use mtr (= Meu TraceRoute ), disponível nos repositórios. Você pode usar algo como

mtr -c 1 -r 8.8.8.8

A primeira opção envia 1 pacote, a opção -r imprime um relatório no final do ciclo e o comando tenta entrar em contato com todos os nós entre o seu PC e o DNS do Google (8.8.8.8). A vantagem de fazer isso é que você obteria um rastreamento de onde, exatamente, sua conexão falha, para que você possa saber se isso ocorre dentro de sua LAN ou fora dela, caso em que você pode ter que reclamar com seu ISP.