Когда мы используем windows ping, он покажет неудачные сообщения. Имеет ли Ubuntu аналогичную функцию?
Неудавшийся пинг весьма полезен при отладке сети. Как вы, ребята, решаете это? Ну, я просто хочу простое решение, я не хочу получать длинный скрипт.
Правильный ответ: нет такой вещи, как «неудачный потерянный пинг». (Отклики Failure, такие как «Destination unreachable», всегда печатаются, они не отличаются от ответа вообще.)
Утилита Ping печатает каждый полученный ответ, даже если он решил, что этот конкретный пинг был потерян.
Даже на моем Android-телефоне утилита ping share поддерживает эти 2 варианта: -D печатает временную метку перед каждым сообщением -O выводит сообщение, когда ответ не получен во времени, и это более или менее то, что было задано. Тем не менее, эти параметры, кажется, не поддерживаются повсюду (например, Debian Wheezy не хватает их, насколько я знаю, в то время как у Джесси есть их. [F2] не поддерживает их).
Вот пример вывода I удалось получить (несущественные ответы на 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, и, наконец, потеря пакетов сообщается как 0.
после
В Windows ping, похоже, ждет ответа дольше, а затем объявит его отсутствующим и проигнорирует его, если он появится позже.
По умолчанию интервал составляет 1 секунду, а таймаут - 4 секунды, поэтому: При низком RTT пины будут отправляться с интервалом в 1 секунду. В RTT> 4 пинги будут отправляться с 4-секундными интервалами (или 5, не уверены), и все будут сообщены как сбойные, так же, как если бы сервер не ответил.
Отчасти от ответа EvgEnZh, но с моей собственной версией:
ping -O -q 8.8.8.8
Это заставляет его печатать сообщение, когда ответ занимает слишком много времени или никогда не возвращается (-O) и подавляет сообщения, когда они вернутся (-q). В результате вы получаете результат только при отсутствии пакетов. Это может облегчить поиск прерывистых проблем, сделав это, поэтому вам не нужно просеивать кучу сообщений «это сработало» для нескольких мест, которые он сломал.
Возможно, ping -f подходит для вас. Из руководства ping:
-f Пиратский поток. Для каждого отправленного ECHO_REQUEST периода ''. '' Печатается, а навсегда ECHO_REPLY получает обратное пространство. Это обеспечивает быстрое отображение количества пакетов. Если интервал не задан, он устанавливает интервал в ноль и выводит пакеты так же быстро, как они возвращаются, или сто раз в секунду, в зависимости от того, что больше. Только суперпользователь может использовать эту опцию с нулевым интервалом.За 1 echo_request каждую секунду он будет выглядеть как ping -i 1 -f 8.8.8.8
Даже с опцией -v пинг этого не делает. См. Этот вопрос. Но если это действительно важно (или весело) для вас, вы можете загрузить источник, изменить код, чтобы включить подходящий вызов printf. Хорошее место для этого было бы в конце метода send_probe (строка 619, 12.10) ...
Сначала вы получаете источник
apt-get source iputils
cd iputils*
Сделайте изменения [ ! d3]
gedit ping.c
Сборка и установка сгенерированного пакета ...
apt-get install libsysfs-dev
dpkg-buildpackage