-1

Это своего рода продолжение этого вопроса.

В конце концов, моя цель - использовать 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, а также на моем MacBook Air с OS X 10.11.2. Поэтому я подумал, что могу использовать то же самое на Пи. Но затем появилась первая ошибка.

$ ping 8.8.8.8

ping: icmp open socket: Operation not permitted

Чтобы обойти это, я начал пинговать как супер-пользователь:

$ 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

Теперь вы можете подумать, что это решает мою проблему, но нет, после этого я заметил еще одну проблему. Команда ping на Pi не выводит тайм-ауты запроса. Поэтому, когда время пакета истекло, 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 8.8.8.8 чтобы узнать, является ли это соединением с роутером или действительно соединением с Google.

Следующие результаты приводят к одинаковому результату в обеих системах:

$ ping -V

ping utility, iputils-s20121221

После некоторого осмотра я нашел на странице руководства вариант ping для Pi, который в некоторой степени делает то, что я хочу:

$ 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

Но если мое понимание верно, то это отличается тем, что команда ping в ubuntu выводит сообщение, только если ответ не получен до истечения времени ожидания, даже если другой пакет ping был отправлен до получения ответа. Команда ping на моем Pi также выводит сообщение, когда ответ будет восстановлен после получения сообщения.

Так почему же это отличается от Pi от сервера Ubuntu? Как я могу достичь своей цели?

Вопрос также размещен на raspberrypi.stackexchange.com.

1 ответ1

3

Прежде всего, следующая команда

 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 (= My TraceRoute), доступный в репозиториях. Вы можете использовать что-то вроде

mtr -c 1 -r 8.8.8.8

Первая опция отправляет 1 пакет, опция -r печатает отчет в конце цикла, и команда пытается связаться со всеми узлами между вашим компьютером и DNS Google (8.8.8.8). Преимущество этого состоит в том, что вы получите информацию о том, где именно разорвано ваше соединение, чтобы вы могли знать, происходит ли это внутри вашей локальной сети или за ее пределами, и в этом случае вам, возможно, придется обратиться к вашему интернет-провайдеру.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .