☰

Ping 未按预期工作

tag-icon • tag-icon linux networking bash ping raspberry-pi
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 Server 以及搭载 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

这表明只icmp_sequences发送了 151 个不同的消息，而丢失的消息只是一遍又一遍地重新发送。

我还应该补充一点，192.168.2.1除了谷歌之外，我还 ping 了我的本地路由器8.8.8.8，以查看它是否是与路由器的连接，或者是否真的是与谷歌的连接。

以下操作在两个系统上产生相同的输出：

$ ping -V

ping utility, iputils-s20121221

经过一番寻找，我在 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

但是如果我的理解是正确的，那么这与 ubuntu 上的命令不同，ping只有在超时之前未收到答案时，该命令才会输出消息，即使在收到答案之前发送了另一个 ping 包。ping当收到消息后答案将恢复时，我的 Pi 上的命令也会打印出该消息。

那么，为什么 Pi 和 Ubuntu 服务器上的情况有所不同？我该如何实现我的目标？

问题还发布在raspberrypi.stackexchange.com。

答案1

首先，以下命令

 sudo chmod u+s `which ping`

ping对于非 su 用户也有效。

其次，你可以用下面的方法解决你的问题，

ping -c 1 -W 1 192.168.0.1

第一个选项发送单个数据包，第二个选项设置一个超时期限，超过该期限，数据包将被声明为丢失，并打印错误消息。例如，

$ 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，等待回复，只有我的Ctrl+C停止了等待，没有产生任何输出。但在第二种情况下，使用-W 1（= 等待 1 秒，然后放弃）会立即产生一条错误消息。

但第三，我建议你使用mtr（=我的 TraceRoute)，可从存储库获取。您可以使用类似

mtr -c 1 -r 8.8.8.8

第一个选项发送 1 个数据包，该-r选项在循环结束时打印一份报告，并且该命令尝试联系您的 PC 和 Google 的 DNS (8.8.8.8) 之间的所有节点。这样做的好处是，您可以跟踪您的连接中断的确切位置，以便您可以知道这是发生在您的 LAN 内部还是外部，在这种情况下，您可能需要向您的 ISP 投诉。

相关内容