¿Cómo mostrar un ping fallido?

24

Cuando usamos el ping de Windows, mostrará los pings fallidos. ¿Ubuntu tiene una función similar?

El ping fallido es bastante útil al depurar la red. ¿Cómo ustedes resuelven esto? Bueno, solo quiero una solución simple, no quiero obtener un guión largo.

ping

— 王子 1986
fuente

2

¿Puede proporcionar una salida de muestra o una captura de pantalla para complementar la pregunta?

— verde

1

¿Está buscando información más detallada que 5 packets transmitted, 0 received, 100% packet loss, time 4032ms(información como esa se imprime cuando termina el ping, ya sea solo o mediante Ctrl + C)? ¿Está buscando datos separados sobre cada ping individual?

— Eliah Kagan

1

Linux es increíble y todos los que estamos aquí lo amamos por muchas razones, pero ... oye, a veces Windows lo hizo bien y Linux lo hizo mal. Sí, incluso en herramientas básicas de CLI. Sí, incluso en las herramientas básicas de CLI para redes. Si no hay una manera fácil de obtener un mensaje en la pantalla cuando las cosas salen mal, entonces debemos reconocerlo como "una característica que nos falta". Ciertamente no queremos fingir que es algo tan complejo que no podemos entender qué es exactamente lo que pregunta el OP (especialmente cuando es una función activada por defecto en unos pocos millones de cajas a nuestro alrededor).

— ndemou

Podría haber jurado que esta característica estaba presente en linux ping anterior. También está presente en MacOS (que está construido sobre Unix). Está más allá de mí por qué no debería estar allí. Tengo una línea que funciona de manera intermitente y para averiguar la duración de los apagones necesito tamizar a través de la salida buscando salto, en lugar de tener las líneas claramente distintas.

— Silvio Levy

26

La respuesta correcta es: no hay tal cosa como " ~~fallido~~ de ping perdido". (Las respuestas de falla como "Destino inalcanzable" siempre se imprimen, es diferente de ninguna respuesta).

La utilidad Ping imprime cada respuesta recibida, incluso si Eatlier decidió que se perdió este ping específico. Es totalmente posible recibir respuestas fuera de orden.

Incluso en mi teléfono Android, la utilidad stock ping admite estas 2 opciones:
-D imprime una marca de tiempo antes de cada mensaje
-O imprime un mensaje cuando la respuesta no se recibe a tiempo, y es más o menos lo que se solicitó .
Sin embargo, estas opciones no parecen ser compatibles en todas partes (por ejemplo, Debian Wheezy no las tiene hasta donde yo sé, mientras que Jessie las tiene. busybox pingNo las admite).

Aquí hay un ejemplo de salida que logré obtener (respuestas de ping sin importancia omitidas):

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

Observe cómo se informa primero que falta el # 130, luego se recibe después del # 131, y finalmente se informa que la pérdida de paquetes es cero.

Nota adicional sobre Windows:

En Windows, el ping parece esperar más tiempo para responder y luego declarar que falta e ignorarlo si llega más tarde.

De manera predeterminada, el intervalo es de 1 segundo y el tiempo de espera es de 4 segundos, por lo tanto:
en RTT bajo, los pings se enviarán con intervalos de 1 segundo.
En RTT> 4, los pings se enviarán con intervalos de 4 segundos (o 5, no estoy seguro) y todos se informarán como fallidos, igual que si el servidor no respondiera.

— EvgEnZh
fuente

1

+1 para la -Oopción, está presente y funciona bien en Ubuntu de confianza (y Linux Mint 17.2) desde el paquete iputils-ping versión 3: 20121221-4ubuntu1.1

— Xen2050

11

Desviando parcialmente la respuesta de EvgEnZh, pero con mi propia versión:

ping -O -q 8.8.8.8

Eso hace que imprima un mensaje cuando una respuesta tarda demasiado o nunca regresa ( -O) y suprime los mensajes para cuando regresan ( -q). El resultado es que solo obtienes resultados cuando faltan paquetes. Esto puede hacer que la búsqueda de problemas intermitentes sea mucho más fácil al hacer que no tenga que examinar una pila de mensajes de "funcionó" en los pocos lugares donde se rompió.

— Azendale
fuente

Tenga en cuenta que la activación de -O solo significa que la latencia es mayor de lo esperado. Eso a menudo indica un problema real, pero no siempre. El registro que publiqué en mi respuesta fue adquirido en una conexión GPRS débil, y aunque en más de 2 minutos solo capté una respuesta fuera de orden, hubo muchas respuestas que llegaron "tarde". La conexión de mierda se vio abrumada varias veces, informó que faltaban varios pings seguidos, y luego todos entraron después de unos segundos. La conexión aún era confiable (tal vez GPRS manejó la retransmisión internamente, no lo sé), solo un dolor extremo de usar incluso para el acceso SSH.

— EvgEnZh

3

Tal vez ping -fsea adecuado para ti. Desde el manual de ping:

-F

Inundación de ping. Por cada ECHO_REQUEST enviado se imprime un punto ''. '', Mientras que para ECHO_REPLY recibido se imprime un retroceso. Esto proporciona una visualización rápida de cuántos paquetes se están descartando. Si no se proporciona el intervalo, establece el intervalo en cero y genera paquetes tan rápido como regresan o cien veces por segundo, lo que sea más. Solo el superusuario puede usar esta opción con intervalo cero.

Por 1 echo_request cada segundo se vería como ping -i 1 -f 8.8.8.8

— Daniel Yuste Aroca
fuente

No estoy seguro de si es una característica nueva o no, pude ver los pings fallidos.

— 王子 1986

¿Qué opción usaste para informar los pings fallidos? ¿Qué mensaje recibes por un ping fallido?

— Daniel Yuste Aroca

Si bien acabo de usar ping, el mensaje es así $ ping 172.18.1.12 PING 172.18.1.12 (172.18.1.12) 56 (84) bytes de datos. Desde 172.18.1.224 icmp_seq = 1 host de destino inalcanzable Desde 172.18.1.224 icmp_seq = 2 host de destino inalcanzable desde 172.18.1.224 icmp_seq = 3 host de destino inalcanzable

— 王子 1986

2

"Host de destino inalcanzable" no es lo mismo que un tiempo de espera de ping

— ndemou

ping -f no es la respuesta, porque no deja un registro. Lo que se necesita es un tipo de línea para un ping exitoso y otro diferente para una falla, por lo que uno puede saber de inmediato (en una situación donde el servicio es intermitente) con qué frecuencia y durante cuánto tiempo son los apagones.

— Silvio Levy

0

Incluso con la opción -v, ping no hace eso. Ver esta pregunta . Pero si esto es realmente importante (o divertido) para usted, puede descargar la fuente, modificar el código para incluir una llamada printf adecuada. Un buen lugar para eso sería al final del método 'send_probe' (línea 619 en 12.10) ...

Primero obtienes la fuente

apt-get source iputils
cd iputils*

Hacer ediciones

gedit ping.c

Compilar e instalar el paquete generado ...

apt-get install libsysfs-dev
dpkg-buildpackage

— Rémi
fuente

Me gustaría hacer esto (y votar esta respuesta 10 veces) pero debe haber algo que falta. Estoy trabajando bajo sudo -s. Después de editar ping.c, si intento "hacer" me sale "error grave: sys / capacidad.h: No existe ese archivo". Si sigo las siguientes dos líneas en la respuesta (apt-get install y dpkg -...) no obtengo errores pero no tengo idea de dónde se ubica el ejecutable. El antiguo ejecutable (/ bin / ping) todavía está allí: sé que es antiguo por la marca de tiempo y porque no se comporta de manera diferente.

— Silvio Levy

-1

Gracias por todas las respuestas. Parece que el último ping de ubuntu puede mostrar que el ping falló.

Gracias de nuevo.

— 王子 1986
fuente

1

No, no lo hace (hasta 2015-enero por lo menos) "Host de destino inaccesible" no es lo mismo que un tiempo de espera de ping

— ndemou

¿Por qué es esta la respuesta aceptada? ping -O -q 8.8.8.8es el camino a seguir

— theV0ID