¿Por qué el mismo comando ping se comporta completamente diferente en dos sistemas?

1

El software

Servidor Ubuntu:

ubuntu@server: $ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=wily
DISTRIB_DESCRIPTION="Ubuntu 15.10"
NAME="Ubuntu"
VERSION="15.10 (Wily Werewolf)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.10"
VERSION_ID="15.10"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

ubuntu@server: $ ping -V
ping utility, iputils-s20121221

Raspberry Pi 1 Modelo B:

pi@raspberrypi: $ cat /etc/*-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@raspberrypi: $ ping -V
ping utility, iputils-s20121221

El resultado esperado

ubuntu@server: $ ping -c 4 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=55 time=17.3 ms
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=14.1 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3001ms
rtt min/avg/max/mdev = 14.172/15.922/17.340/1.312 ms

La parte importante es el paquete que falta, esto es como lo esperaría, si un paquete se pierde O tarda mucho tiempo, el comando ping debería imprimir un Request timeoutmensaje ... pero en la Raspberry Pi ...

El resultado real

pi@raspberrypi: $ ping -c 4 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.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=13.2 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 3002ms
rtt min/avg/max/mdev = 12.289/12.724/13.284/0.397 ms

Si no mira lo suficientemente cerca, puede perderse lo que está mal. Pero 5 packets transmittedno imprimió Request timeoutni pasó al siguiente icmp_seq, simplemente reenvió el paquete perdido sin ningún error, y solo descubrirá si un paquete se perdió si lee el resumen al final.

La pregunta

¿Por qué la misma pingversión se comporta de manera diferente en sistemas diferentes?

¿Tiene el comando ping una configuración en algún lugar que pueda editar para que se comporte igual?

ubuntu command-line ping raspberry-pi usbpc102
fuente
Si ejecuta su ping por segunda vez desde el PI, ¿ve el mismo comportamiento? Ese primer paquete podría perderse porque su sistema está buscando la puerta de enlace predeterminada. Pero solo lo vería la primera vez que haga ping con una tabla arp clara.
Zoredache
Lo siento, no entiendo completamente lo que quieres que haga. Pero -cejecuté el Pi sin la opción durante toda una noche y me perdí algunos paquetes de hunderet, pero no recibí ningún Request timeoutmensaje. Pude ver los paquetes que faltan en el resumen al final.
usbpc102
Lo siento, estaba tratando de hacerte entender esto. blog.ipspace.net/2007/04/why-is-first-ping-lost.html Que creo que es cuál es su problema en el ping de 'pi'. Es decir, el primer paquete se está perdiendo en un ARP. No estoy seguro de cuáles son tus otros problemas.
Zoredache
Ah, sí, eso explicaría el paquete perdido. PERO mi pregunta solo muestra un breve resultado de ejemplo. Como se puede ver en lo que se espera es un Request timeout, ya que mi conexión a Internet lamentablemente se cae. Además, no tengo el control perfecto para soltar un paquete, así que esto es solo una recreación. Y como dije en mi otro comentario: El problema no es que UN paquete se pierde / es demasiado lento, sino que no recibo un mensaje si eso sucede como en el servidor ubuntu cuando un paquete se pierde / es demasiado lento. Espero haber aclarado un poco más mi problema. ;) (
Mejoraré
No, tu pregunta no está clara. Un ping tiene muchas formas de fallar, y dependiendo del problema específico y la configuración de red de otros dispositivos en su red, recibirá diferentes mensajes de error. No tiene suficiente información para hacer declaraciones útiles sobre algo en este momento.
Zoredache