NOM¶

ping, ping6 - Envoyer des datagrammes ICMP ECHO_REQUEST à des hôtes sur un réseau

SYNOPSIS¶

ping [ -LRUbdfnqrvVaA] [ -c nombre] [ -i intervalle] [ -l préchargement] [ -p motif] [ -s taille-paquet] [ -t ttl] [ -w heure-limite] [ -F étiquette-flux] [ -I interface] [ -M conseil] [ -Q tos] [ -S tampon-émission] [ -T option-horodate] [ saut ...] destination

DESCRIPTION¶

ping utilise le datagramme obligatoire ECHO_REQUEST du protocole ICMP pour requérir une réponse ICMP ECHO_RESPONSE d'un hôte ou d'une passerelle. Les datagrammes ECHO_REQUEST (« pings ») comportent les en-têtes IP et ICMP, suivis d'une « struct timeval » et d'un nombre arbitraire d'octets de bourrage utilisés pour remplir le paquet.

OPTIONS¶

-a

ping audible.

-A

ping adaptatif. L'intervalle inter-paquets s'adapte au délai aller-retour (round-trip time, rtt), afin qu'il n'y ait pas plus d'une sonde sans réponse (ou plus, si le préchargement est utilisé) sur le réseau. L'intervalle minimal est de 200 ms pour les utilisateurs normaux (non super-utilisateurs). Sur les réseaux de rtt faible, ce mode est quasiment équivalent au mode inondation.

-b

Permettre de « pinger » une adresse de diffusion (broadcast).

-c nombre

S'arrêter après l'envoi de nombre paquets ECHO_REQUEST. Avec l'option heure-limite, ping attend jusqu'à nombre paquets ECHO_REPLY avant que la temporisation n'expire.

-d

Spécifier l'option SO_DEBUG sur la socket utilisée. Cette option de socket n'est essentiellement pas utilisée par le noyau Linux.

-F étiquette-flux

Allouer et spécifier une étiquette de flux (sur 20 bits) dans les paquets de requête d'écho (ping6 uniquement). Si la valeur est nulle, le noyau alloue une étiquette de flux aléatoire.

-f

Mode inondation. Pour chaque ECHO_REQUEST envoyé, un point est affiché, alors que pour chaque ECHO_REPLY reçu, un backspace (effacement arrière) est affiché. Cela fournit un affichage rapide du nombre de paquets qui ont été jetés. Si aucun intervalle n'est fourni, ping fixe l'intervalle à zéro et émet des paquets dès qu'en reviennent d'autres, avec un minimum de 100 fois/s. Seul le super-utilisateur peut utiliser cette option avec un intervalle nul.

-i intervalle

Attendre intervalle secondes entre chaque envoi de paquet. Le délai par défaut est normalement d'une seconde, ou nul en mode inondation. Seul le super-utilisateur peut fixer l'intervalle à des valeurs inférieures à 0.2 secondes.

-I adresse-interface

Fixer l'adresse source à l'adresse de l'interface spécifiée. L'argument peut être une adresse IP numérique ou le nom d'un périphérique. Cette option est requise quand on désire joindre une adresse IPv6 locale au lien.

-l préchargement

Si préchargement est spécifié, ping envoie ce nombre de paquets sans attendre de réponse. Seul le super-utilisateur peut sélectionner un préchargement supérieur à 3.

-L

Enlever la boucle locale des adresses réceptrices des paquets multidestinataires (multicast). Ce drapeau ne s'applique que si la destination du ping est une adresse multidestinataire.

-n

Sortie numérique uniquement. Ne pas essayer de trouver les noms symboliques correspondant aux adresses d'hôtes.

-p motif

Vous pouvez spécifier jusqu'à 16 octets de bourrage pour remplir entièrement le paquet à envoyer. C'est utile pour diagnostiquer des problèmes dépendant des données dans un réseau. Par exemple, -p ff forcera le remplissage du paquet envoyé avec des un.

-Q tos

Spécifier les bits relatifs à la Qualité de Service dans les datagrammes ICMP. tos peut être un nombre décimal ou hexadécimal. Traditionnellement (RFC 1349), les numéros de bits sont interprétés comme suit : 0 est réservé (actuellement en cours de redéfinition pour le contrôle de congestion), 1-4 pour le type de service (Type of Service, ToS), et 5-7 pour la Priorité. Les valeurs possibles pour le type de service sont : coût minimal : 0x02, fiabilité : 0x04, débit : 0x08, bas délai : 0x10. Plusieurs bits de TOS ne devraient pas être utilisés simultanément. Les possibilités pour la Priorité vont de priorité normale (0x20) à supervision réseau (0xe0). Vous devez être root (capacité CAP_NET_ADMIN) pour utiliser la priorité Critique ou une valeur de plus haute priorité. Vous ne pouvez pas positionner le bit 0x01 (réservé) à moins que l'ECN (NdT : Explicit Congestion Notification, notification explicite de congestion) n'ait été activée dans le noyau. Dans le RFC 2474, ces champs ont été redéfinis pour former un champ de 8 bits destiné aux services différenciés (Differentiated Services, DS), constitué des bits 0-1 de données indépendantes (ECN sera utilisé ici), et des bits 2-7 du Differentiated Services Codepoint (DSCP).

-q

Sortie silencieuse. Rien n'est affiché à part les lignes de résumé au démarrage et à la fin de l'exécution.

-R

Enregistrer la route. Inclut l'option RECORD_ROUTE dans le paquet ECHO_REQUEST et affiche (le tampon de) la route dans les paquets retournés. Notez que l'en-tête IP ne peut contenir qu'au plus neuf de ces routes. Beaucoup d'hôtes ignorent ou désactivent cette option.

-r

Ne pas utiliser les tables de routage normales et envoyer les paquets directement à un hôte présent sur une interface directement connectée. Si l'hôte n'est pas situé dans un réseau directement connecté, une erreur est renvoyée. Cette option peut être utilisée pour pinger un hôte local au travers d'une interface ne faisant partie d'aucune route à condition que l'option -I soit également utilisée.

-s taille-paquet

Spécifie le nombre d'octets de données à envoyer. Le nombre par défaut est 56, ce qui se traduit en 64 octets de données ICMP quand ils sont combinés avec les 8 octets de données de l'en-tête ICMP.

-S tampon-émission

Fixer le tampon d'émission de la socket. S'il n'est pas spécifié, on en choisit un ne pouvant contenir plus d'un paquet.

-t ttl

Spécifier le champ IP Time to Live.

-T option-horodate

Spécifier des options d'horodates IP spéciales. L'option-horodate peut être tsonly (uniquement les horodates), tsandaddr (horodates et adresses) ou tsprespec hôte1 [hôte2 [hôte3 [hôte4]]] (sauts préspécifiés horodatés).

-M conseil

Sélectionner la stratégie de découverte de la MTU (NdT : Maximum Transfer Unit, unité de transfert d'information maximale) du chemin (Path MTU Discovery). conseil peut être soit do (ne pas fragmenter, même en local), want (effectuer la découverte du PMTU, fragmenter localement quand la taille du paquet est importante), ou dont (ne pas spécifier le drapeau DF).

-U

Afficher le temps de latence total utilisateur-à-utilisateur (l'ancien comportement). Normalement, ping affiche le rtt du réseau, qui peut être différent p.ex. à cause d'échecs du DNS.

-v

Sortie verbeuse.

-V

Afficher le numéro de version et se terminer.

-w heure-limite

Spécifier un délai, en secondes, avant que ping ne se termine quel que soit le nombre de paquets envoyés ou reçus. Dans ce cas, ping ne s'arrêtera pas après l'envoi de nombre paquets, mais attendra que le délai expire ou que nombre sondes aient reçu une réponse, ou encore qu'une notification d'erreur provienne du réseau.

Quand vous utilisez ping pour la localisation de pannes, il devrait d'abord être exécuté sur l'hôte local, pour vérifier que l'interface réseau locale est activée et fonctionne correctement. Ensuite, les hôtes et les passerelles de plus en plus éloignés devraient être « pingés ». Les délais aller-retour et les statistiques de perte de paquets sont calculés. Si des paquets dupliqués sont reçus, ils ne sont pas inclus dans le calcul des pertes de paquets, bien que leur délai aller-retour soit utilisé pour déterminer les délais aller-retour min/max/moyen. Quand le nombre de paquets spécifié a été envoyé (et reçu), ou si le programme est terminé par un SIGINT, un bref résumé est affiché. Des statistiques actuelles plus courtes peuvent être obtenues sans terminer le processus en utilisant le signal SIGQUIT.

Si ping ne reçoit aucun paquet en réponse, il se terminera avec un code de retour de 1. Si une heure-limite et un nombre de paquets sont tous deux spécifiés, et que moins de nombre paquets ont été reçus avant l'heure-limite, ping se terminera également avec un code de retour de 1. En cas d'autre erreur, le code de retour est 2. Sinon, il s'agit de 0. Cela permet d'utiliser le code de sortie pour déterminer si un hôte est actif ou non.

Ce programme est destiné aux cas de tests, de mesure, et de gestion de réseaux. À cause de la charge qu'il impose sur le réseau, il n'est pas très indiqué d'utiliser ping en temps normal, ou à partir de scripts automatisés.

DÉTAILS D'UN PAQUET ICMP¶

Un en-tête IP sans option comporte 20 octets. Un paquet ICMP ECHO_REQUEST contient 8 octets supplémentaires d'en-tête ICMP suivis d'une quantité arbitraire de données. Quand une taille-paquet est fournie, elle indique la taille de cette partie de données supplémentaires (56 octets par défaut). Par conséquent, la quantité de données reçues à l'intérieur d'un paquet IP de type ICMP ECHO_REPLY sera toujours de 8 octets supérieure à l'espace requis par les données (l'en-tête ICMP).

Si l'espace occupé par les données est d'au moins la taille d'une struct timeval, ping utilise les huit premiers octets de cet espace pour inclure une horodate qu'il utilise dans le calcul des délais aller-retour. Si l'espace des données est plus faible, aucun délai aller-retour n'est donné.

PAQUETS DUPLIQUÉS ET ENDOMMAGÉS¶

ping signalera les paquets dupliqués ou endommagés. Une duplication de paquets ne devrait jamais se produire, et semble être causée par des retransmissions inadéquates au niveau liaison de données. Les duplications peuvent se produire dans de nombreuses situations, et sont rarement (pour ne pas dire jamais) un bon signe, bien que la présence d'une basse proportion de paquets dupliqués ne doive pas toujours vous inquiéter.

Les paquets endommagés constituent évidemment une cause sérieuse d'alerte et indiquent souvent une panne matérielle quelque part sur le chemin du paquet ping (dans le réseau ou dans les hôtes).

TESTER DES MOTIFS DE DONNÉES DIFFÉRENTS¶

La couche (inter)réseau ne devrait jamais traiter des paquets différemment en fonction des données contenues dans la partie de données. Malheureusement, on a signalé des problèmes dépendants des données qui s'immiscent dans les réseaux et restent non détectés pendant une longue période de temps. Dans beaucoup de cas, le motif particulier qui aura des problèmes est un motif ne comportant pas suffisamment de « transitions », comme par exemple tous des un ou tous des zéros, ou bien un motif proche (comme par exemple presque uniquement des zéros). Il ne suffit pas nécessairement de spécifier un motif de données ne comportant que des zéros (par exemple) sur la ligne de commandes étant donné que le motif qui entre en jeu est celui qui se trouve au niveau liaison de données, et que la relation entre ce que vous tapez et ce qui sera réellement envoyé sur le réseau par les contrôleurs peut être complexe.

Cela signifie que si vous avez un problème dépendant des données, alors vous devrez probablement effectuer beaucoup de tests pour le trouver. Si vous avez de la chance, vous pouvez trouver un fichier qui ne peut être envoyé sur votre réseau, ou qui prend beaucoup plus de temps à être transféré que d'autres fichiers de longueur similaire. Vous pouvez ensuite examiner ce fichier pour trouver des motifs répétés que vous pouvez tester en utilisant l'option -p de ping.

DÉTAILS SUR LE TTL¶

La valeur TTL (Time To Live, temps de vie) d'un paquet IP représente le nombre maximum de routeurs IP que ce paquet est autorisé à traverser avant d'être jeté. Dans la pratique, vous pouvez vous attendre à ce que chaque routeur sur Internet décrémente le champ TTL d'exactement une unité.

La spécification TCP/IP précise que le champ TTL destiné aux « paquets » TCP devrait être fixé à 60, mais beaucoup de systèmes utilisent des valeurs plus petites (BSD 4.3 utilise 30, la version 4.2 utilisait 15).

La valeur maximale pour ce champ est de 255, et la plupart des systèmes Unix fixent le champ TTL des paquets ICMP ECHO_REQUEST à 255. C'est pourquoi vous pouvez « pinger » certains hôtes, mais pas les atteindre via telnet(1) ou ftp(1).

Normalement, ping affiche la valeur TTL du paquet qu'il reçoit. Quand un système distant reçoit un paquet ping, il peut faire 3 choses avec le champ TTL dans sa réponse :

•

Ne pas le modifier ; c'est ce que faisaient les systèmes Unix Berkeley avant la version BSD 4.3 tahoe. Dans ce cas, la valeur TTL du paquet reçu sera de 255 moins le nombre de routeurs traversés sur le chemin aller-retour.

•

Le fixer à 255 ; c'est ce que font les systèmes Unix Berkeley actuels. Dans ce cas, la valeur TTL du paquet reçu sera de 255 moins le nombre de routeurs traversés sur le chemin venant du système distant vers l'hôte effectuant le ping.

•

Le fixer à une autre valeur. Certaines machines utilisent la même valeur pour les paquets ICMP que pour les paquets TCP, par exemple 30 ou 60. D'autres peuvent utiliser des valeurs complètement aléatoires.

BOGUES¶

•

Beaucoup d'hôtes et de passerelles ignorent l'option RECORD_ROUTE.

•

La taille maximale de l'en-tête IP est trop courte pour que des options comme RECORD_ROUTE soient vraiment utiles. On ne peut pourtant pas y faire grand chose.

•

L'inondation de pings n'est en général pas recommandée, et inonder de pings l'adresse de diffusion générale (broadcast) ne devrait être fait que dans des circonstances très particulières.

VOIR AUSSI¶

netstat(1), ifconfig(8).

HISTORIQUE¶

La commande ping est apparue dans BSD 4.3.

La version décrite ici est son descendant spécifique à Linux.

SÉCURITɶ

ping requiert la capacité CAP_NET_RAWIO pour pouvoir être exécuté. Il peut être utilisé dans le mode set-uid root.

DISPONIBILITɶ

ping fait partie du paquetage iputils ; les dernières versions sont disponibles sous forme de code source via ftp anonyme sur ftp://ftp.inr.ac.ru/ip-routing/iputils-current.tar.gz.

TRADUCTION¶

Frédéric Delanoy <delanoy_f at yahoo.com>, 2002.