Как показать проваленный пинг?

24

Когда мы используем пинг Windows, он покажет сбой пингов. У Ubuntu есть подобная функция?

Сбой ping весьма полезен при отладке сети. Как вы, ребята, решаете это? Ну, я хочу только простое решение, я не хочу получать длинный сценарий.

ping

— 王子 1986
источник

2

Можете ли вы предоставить пример вывода или скриншот, чтобы дополнить вопрос?

— зеленый

1

Вы ищете или более подробную информацию, чем 5 packets transmitted, 0 received, 100% packet loss, time 4032ms(информация наподобие этой выводится, когда пинг завершается, сам по себе или по Ctrl + C)? Вы ищете отдельные данные о каждом пинге?

— Элия Каган

1

Linux потрясающий, и все мы здесь любим его по многим причинам, но ... эй, иногда Windows понимает это правильно, а Linux понимает это неправильно. Да, даже в основных инструментах CLI. Да, даже в основных сетевых инструментах CLI! Если нет простого способа вывести сообщение на экран, когда что-то идет не так, то мы должны признать это как «функцию, которую нам не хватает». Мы, конечно, не хотим притворяться, что это что-то настолько сложное, что мы не можем понять, что именно запрашивает OP (особенно, когда эта функция включена по умолчанию в нескольких миллионах рамок вокруг нас).

— ndemou

Я мог бы поклясться, что эта функция присутствовала в более ранних версиях Linux. Он присутствует и в MacOS (который построен поверх unix). Это вне меня, почему это не должно быть там. У меня есть линия, которая работает с перебоями, и чтобы узнать длину отключений, мне нужно просеять через выход в поисках прыжка, вместо того, чтобы линии были четко различимы.

— Сильвио Леви

26

Правильный ответ: нет такой вещи, как « ~~неудачный~~ потерянный пинг». (Ответы о сбое, такие как «Место назначения недоступно», всегда печатаются, они отличаются от отсутствия ответа вообще.)

Утилита Ping печатает каждый полученный ответ, даже если она решила, что этот конкретный пинг потерян. Вполне возможно получать ответы не по порядку.

Даже на моем Android-телефоне стандартная утилита ping поддерживает следующие 2 опции:
-D печатает временную метку перед каждым сообщением
-O печатает сообщение, когда ответ не получен вовремя, и это больше или меньше того, что было задано .
Однако эти параметры, похоже, не поддерживаются повсеместно (например, насколько мне известно, в Debian Wheezy их нет, в то время как у Джесси они есть. busybox pingНе поддерживает их).

Вот пример выходных данных, которые мне удалось получить (неважные ответы на пинг пропущены):

u0_a93@NX505J:/ $ ping -D -O 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
[1440545014.805478] 64 bytes from 8.8.8.8: icmp_seq=1 ttl=244 time=116 ms
~~~~~~~~~~
[1440545142.995443] 64 bytes from 8.8.8.8: icmp_seq=129 ttl=244 time=110 ms
[1440545144.885601] no answer yet for icmp_seq=130
[1440545145.455485] 64 bytes from 8.8.8.8: icmp_seq=131 ttl=244 time=568 ms
[1440545145.455780] 64 bytes from 8.8.8.8: icmp_seq=130 ttl=244 time=1569 ms
[1440545146.005850] 64 bytes from 8.8.8.8: icmp_seq=132 ttl=244 time=119 ms
~~~~~~~~~~
[1440545254.055962] 64 bytes from 8.8.8.8: icmp_seq=240 ttl=244 time=115 ms
^C
--- 8.8.8.8 ping statistics ---
240 packets transmitted, 240 received, 0% packet loss, time 239250ms
rtt min/avg/max/mdev = 109.062/138.757/1569.620/101.608 ms, pipe 2

Обратите внимание, что # 130 сначала сообщается как пропавший без вести, а затем принимается после # 131, и, наконец, потеря пакета считается равной нулю.

Дополнительное примечание о Windows:

В Windows ping, похоже, дольше ждет ответа, а затем объявляет его отсутствующим и игнорирует его, если он приходит позже.

По умолчанию интервал составляет 1 секунду, а тайм-аут - 4 секунды, поэтому: при
низком RTT пинг будет отправляться с интервалом в 1 секунду.
При RTT> 4, пинг будет отправляться с 4-секундными интервалами (или 5, не уверен), и все будут сообщаться как сбой, как если бы сервер не ответил

— EvgEnZh
источник

1

+1 для -Oопции, присутствует и хорошо работает в Ubuntu trusty (& Linux Mint 17.2) из пакета 3 пакета iputils-ping: 20121221-4ubuntu1.1

— Xen2050

11

Отхожу частично от ответа ЕвгЭнЖ, но с моей собственной версией:

ping -O -q 8.8.8.8

Это заставляет печатать сообщение, когда ответ занимает слишком много времени или никогда не возвращается ( -O), и подавляет сообщения, когда они возвращаются ( -q). В результате вы получаете вывод только тогда, когда пакеты пропадают. Это может упростить поиск периодически возникающих проблем, сделав его таким образом, чтобы вам не приходилось просеивать кучу сообщений «все сработало» в тех немногих местах, которые он сломал.

— Azendale
источник

Обратите внимание, что запуск -O означает только то, что задержка выше ожидаемой. Это часто указывает на реальную проблему, но не всегда. Журнал, который я разместил в своем ответе, был получен по слабому GPRS-соединению, и хотя за более чем 2 минуты я обнаружил только один неупорядоченный ответ, было много ответов, которые приходили с «опозданием». Дрянное соединение несколько раз нарушалось, сообщалось о пропаже нескольких пингов подряд, а затем все они пришли через несколько секунд. Соединение было все еще надежным (возможно, GPRS обработал ретрансляцию внутри, я не знаю), просто крайняя боль, которую нужно использовать даже для доступа по SSH.

— ЕвгЭнЖ

3

Может быть ping -f, подходит для вас. Из руководства по пингу:

-f

Флуд пинг. Для каждого отправленного ECHO_REQUEST выводится точка ''. '', В то время как для каждого полученного ECHO_REPLY выводится обратное пространство. Это обеспечивает быстрое отображение количества отбрасываемых пакетов. Если интервал не задан, он устанавливает интервал в ноль и выводит пакеты так же быстро, как они возвращаются или сто раз в секунду, в зависимости от того, что больше. Только суперпользователь может использовать эту опцию с нулевым интервалом.

Для 1 echo_request каждую секунду это будет выглядеть ping -i 1 -f 8.8.8.8

— Даниэль Юсте Арока
источник

Не уверен, что это новая функция или нет, я мог видеть сбой пинг.

— 1986子 1986

Какой вариант вы использовали, чтобы сообщить о неудачных пингах? Какое сообщение вы получаете за неудачный пинг?

— Даниэль Юсте Арока

Хотя я только что использовал ping, сообщение выглядит так: $ ping 172.18.1.12 PING 172.18.1.12 (172.18.1.12) 56 (84) байтов данных. С 172.18.1.224 icmp_seq = 1 хост назначения недоступен С 172.18.1.224 icmp_seq = 2 хост назначения недоступен 172.18.1.224 icmp_seq = 3 хост недоступен

— 子 1986

2

«Хост назначения недоступен» - это не то же самое, что время ожидания пинга

— ndemou

ping -f не является ответом, потому что не оставляет записи. Необходим один тип линии для успешного пинга и другой для сбоя, чтобы можно было сразу сказать (в ситуации, когда обслуживание прерывается), как часто и как долго происходят отключения.

— Сильвио Леви

0

Даже с опцией -v ping этого не делает. Смотрите этот вопрос . Но если это действительно важно (или забавно) для вас, вы можете скачать исходный код, изменить код, чтобы включить подходящий вызов printf. Хорошее место для этого было бы в конце метода 'send_probe' (строка 619 на 12.10) ...

Сначала вы получите источник

apt-get source iputils
cd iputils*

Внести изменения

gedit ping.c

Сборка и установка сгенерированного пакета ...

apt-get install libsysfs-dev
dpkg-buildpackage

— Рэй
источник

Я хотел бы сделать это (и поднять этот ответ 10 раз), но должно быть что-то упущено. Я работаю под sudo -s. После редактирования ping.c, если я пытаюсь «сделать», я получаю «фатальную ошибку: sys /ability.h: такого файла нет». Если я буду следовать следующим двум строкам в ответе (apt-get install и dpkg -...), я не получу ошибок, но понятия не имею, где находится исполняемый файл. Старый исполняемый файл (/ bin / ping) все еще там - я знаю, что он старый из отметки времени и потому что он не ведет себя по-другому.

— Сильвио Леви

-1

Спасибо за ответы на все вопросы. Похоже, что последний пинг Ubuntu может показать сбой пинга.

Еще раз спасибо.

— 王子 1986
источник

1

Нет, это не так (до 2015 года, по крайней мере, до января). «Узел назначения недоступен» - это не то же самое, что время ожидания пинга

— ndemou

Почему это принятый ответ? ping -O -q 8.8.8.8это путь

— theV0ID