pingが期待どおりに機能しない

これは、この質問に対する一種のフォローアップです。

私の最終的な目標は、Raspberry Pi 1 Model Bを使用して、インターネット接続が切断されたときはいつでもログに記録することです。

私は次のコマンドでそれをやろうとしました：

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

上記のコマンドは、Ubuntu 15.10サーバーおよびOS X 10.11.2を搭載したMacBook Airで動作します。だから、私はちょうどPiで同じものを使用できると思った。しかし、その後、最初のエラーが現れました。

$ ping 8.8.8.8

ping: icmp open socket: Operation not permitted

それを回避するために、スーパーユーザーとしてpingを開始しました。

$ 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

これで私の問題は解決されると思いますが、いや、その後に気づいた別の問題があります。pingPi のコマンドは、リクエストタイムアウトを出力しません。したがって、パッケージがタイムアウトになると、Piはそのようなメッセージが予想される場所にそれを再送信します。

Request timeout for icmp_seq 39

しかし、私が得るものは何もありません、明らかにそれは答えを得るまでパッケージを再送しますが、失われたパッケージは最後の要約に表示されます：

--- 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

要約の前の最後の出力は次のとおりです。

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

これは、151種類のみicmp_sequencesが送信され、ドロップされたものが何度も何度も再送信されることを示しています。

192.168.2.1また、Googleに加えてローカルルーターにもpingを実行して8.8.8.8、それがルーターへの接続なのか、実際にはgoogle への接続なのかを確認する必要があります。

次の結果は、両方のシステムで同じ出力になります。

$ ping -V

ping utility, iputils-s20121221

いくつか見て回った後、私はmanページでPiのpingのオプションを見つけました。

$ 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.
[...]

パッケージが遅すぎる場合、次の出力が生成されます。

no answer yet for icmp_seq=499

しかし、私の理解が正しい場合、pingubuntu のコマンドは、応答が受信される前に別のpingパッケージが送信された場合でも、タイムアウト前に応答が受信されない場合にのみメッセージを出力する方法が異なります。pingPi のコマンドは、メッセージが受信された後に回答が復活するときにもメッセージを出力します。

それでは、なぜこれはUbuntuサーバーとPiで異なるのですか？どうすれば目標を達成できますか？

質問はraspberrypi.stackexchange.comにも投稿されました。

まず、次のコマンド

 sudo chmod u+s `which ping`

ようになりますping非SUのユーザーのためにも仕事を。

次に、次のオプションで問題を解決できます。

ping -c 1 -W 1 192.168.0.1

最初のオプションは1つのパケットを送信し、2番目のオプションはタイムアウト期間を設定し、それを超えるとパケットが欠落していると宣言され、エラーメッセージが出力されます。例えば、

$ 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

ご覧のとおり、最初のケースでは（-W 1オプションなしで）ping応答を待っていたため、my Ctrl+ のみが待機をC停止し、出力は生成されませんでした。しかし、2番目のケースでは-W 1（= 1秒間待ってからあきらめて）エラーメッセージがすぐに生成されました。

しかし、第三に、リポジトリから入手できるmtr（= My TraceRoute）を使用することをお勧めします。あなたは次のようなものを使うかもしれません

mtr -c 1 -r 8.8.8.8

最初のオプションは1パケットを送信し、-rオプションはサイクルの終わりにレポートを出力し、コマンドはPCとGoogleのDNS（8.8.8.8）の間のすべてのノードへの接続を試みます。これを行うことの利点は、接続が正確にどこで切断されるかのトレースを取得できることです。これにより、これがLAN内で行われるか、LANの外で行われるかがわかります。