Comment montrer un ping échoué?

Lorsque le ping de Windows affiche "Request timed out.", ce n'est pas une erreur en soi. Microsoft a arbitrairement choisi un délai d'attente de 4 secondes, après quoi ils considèrent "l'échec" et le signalent. Si vous deviez faire un ping depuis Mars, ce serait une fausse alerte garantie, mais même sur Terre, un RTT (temps aller-retour) de plus de 4 secondes est parfaitement possible. Le délai d'attente est configurable avec un commutateur /w .

Sous Linux, l'utilitaire ping ne considère pas que le délai est un échec et n'attend pas de réponse. Normalement, il affiche immédiatement et tel quel, toutes les réponses reçues, y compris les "retardataires", les réponses hors séquence, les doublons et les réponses en conflit (par exemple, une réponse valide après "Destination unreachable").

Cela étant dit, il y a généralement des options pour voir quand une réponse n'est pas reçue trop longtemps. Même sur mon téléphone Android, l'utilitaire ping par défaut prend en charge ces 2 options :

• -D affiche une horodatage avant chaque message, rendant les écarts plus faciles à repérer.
• -O affiche un message lorsque la réponse n'est pas reçue avant d'envoyer le ping suivant, et c'est plus ou moins ce qui était demandé. Le "délai d'attente" est fixé à l'intervalle de ping (-i), cependant.

Cependant, ces options ne semblent pas être prises en charge partout (par exemple, Debian Wheezy ne les prend pas en charge autant que je sache, tandis que Jessie les prend en charge. busybox ping ne les prend pas encore en charge).

Voici un exemple de sortie que j'ai réussi à obtenir (les réponses de ping non importantes ont été ignorées) :

u0_a93@NX505J:/ $ ping -D -O 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) octets de données.
[1440545014.805478] 64 octets de 8.8.8.8: icmp_seq=1 ttl=244 temps=116 ms
~~~~~~~~~~
[1440545142.995443] 64 octets de 8.8.8.8: icmp_seq=129 ttl=244 temps=110 ms
[1440545144.885601] pas encore de réponse pour icmp_seq=130
[1440545145.455485] 64 octets de 8.8.8.8: icmp_seq=131 ttl=244 temps=568 ms
[1440545145.455780] 64 octets de 8.8.8.8: icmp_seq=130 ttl=244 temps=1569 ms
[1440545146.005850] 64 octets de 8.8.8.8: icmp_seq=132 ttl=244 temps=119 ms
~~~~~~~~~~
[1440545254.055962] 64 octets de 8.8.8.8: icmp_seq=240 ttl=244 temps=115 ms
^C
--- 8.8.8.8 statistiques ping ---
240 paquets envoyés, 240 reçus, 0% perte, temps 239250ms
rtt min/moy/max/mdev = 109.062/138.757/1569.620/101.608 ms, pipe 2

Remarquez comment le n°130 est d'abord signalé "manquant", puis reçu après le n°131, et enfin la perte de paquets est signalée comme étant nulle. Le ping de Windows ne donnerait jamais un tel résultat : il attendrait une réponse ou un délai d'attente et enverrait ensuite le ping suivant, ignorant toutes les réponses tardives ou non premières.

Allant partiellement sur la réponse d'EvgEnZh, mais avec ma propre version :

ping -O -q 8.8.8.8

Cela permet d'imprimer un message lorsque la réponse prend trop de temps ou ne revient jamais (-O) et supprime les messages lorsque la réponse revient (-q). Le résultat est que vous n'obtenez de sortie que lorsque les paquets sont manquants. Cela peut faciliter la recherche de problèmes intermittents en vous évitant de devoir trier un tas de messages "ça a fonctionné" pour les quelques endroits où cela a échoué.

Peut-être que ping -f vous convient. À partir du manuel de ping:

-f

Ping en mode inondation. Pour chaque demande ECHO envoyée, un point ''.'' est affiché, et pour chaque réponse ECHO reçue, un retour en arrière est affiché. Cela permet d'afficher rapidement combien de paquets sont perdus. Si l'intervalle n'est pas spécifié, il le règle sur zéro et affiche les paquets aussi rapidement qu'ils reviennent ou cent fois par seconde, selon ce qui est le plus rapide. Seul le super-utilisateur peut utiliser cette option avec un intervalle nul.

Pour un ECHO_REQUEST toutes les secondes, cela ressemblerait à ping -i 1 -f 8.8.8.8

il n'y a pas de "ping perdu échoué". (Les réponses d'échec telles que "Destination inaccessible" sont toujours affichées, c'est différent d'aucune réponse du tout.)

L'utilitaire Ping imprime chaque réponse reçue, même s'il a décidé plus tôt que ce ping spécifique était perdu. Il est tout à fait possible de recevoir des réponses dans le désordre. "

Cela ne semble plus être le cas. Juste un an après que vous ayez posté ceci, iputils/ping s'est cassé et il est maintenant tout à fait possible que rien ne soit imprimé.

https://github.com/iputils/iputils/issues/320

Même avec l'option -v, ping ne le fait pas. Voir cette question. Mais si c'est vraiment important (ou amusant) pour vous, vous pouvez télécharger la source, modifier le code pour inclure un appel printf approprié. Un bon endroit pour le faire serait à la fin de la méthode 'send_probe' (ligne 619 sur 12.10)...

Tout d'abord, vous obtenez la source

apt-get source iputils
cd iputils*

Faire des modifications

gedit ping.c

Construire et installer le package généré...

apt-get install libsysfs-dev
dpkg-buildpackage