J'aimerai comprendre la commande ping

Recherche :

Dernière réponse
Sujet : J'aimerai comprendre la commande ping
Scr@t	Merci, je regarderai cela lundi. Je connais tracert mais je ne crois pas avoir fait attention à l'option w Tracert me sert juste à vérifier que les paquets passent par la bonne route. Je me rends compte d'un coup que je me suis mal expliqué + haut. Ce que je veux en fait, c'est vérifier le cout de mes routes car j'ai encore des connexions multisites en ISDN :cry: L'ADSL, c'est bien beau, mais ce n'est pas encore disponible de partout :lol:

Dernière réponse

Sujet : J'aimerai comprendre la commande ping

Scr@t

Merci, je regarderai cela lundi.
Je connais tracert mais je ne crois pas avoir fait attention à l'option w
Tracert me sert juste à vérifier que les paquets passent par la bonne route.

Je me rends compte d'un coup que je me suis mal expliqué + haut.
Ce que je veux en fait, c'est vérifier le cout de mes routes car j'ai encore des connexions multisites en ISDN :cry:
L'ADSL, c'est bien beau, mais ce n'est pas encore disponible de partout :lol:

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Scr@t

La commande tracert [IP à sonner] OU [URL à sonner] ;)

Tu peux spécifier le paramètre -w suivi du délai d'attente maximal (500 c'est bien), ça t'évite d'attendre inutilement 15 secondes par saut si un routeur ne répond pas (si il bloque les paquets ICMP echo request, ou s'il n'a pas le temps d'y répondre (ICMP est en très faible priorité)).

tentes un "tracert -w 500 www.orange.fr" , tu vas tout de suite comprendre le principe.

C'est l'outil idéal pour tester des tables de routage, bien plus adapté qu'un simple ping.

Scr@t

Merci tom1985

Je pense donc que mon routeur fixe le TTL à 64 de maniere arbitraire.
Comme c'est un Linksys, je suppose que les routeurs CISCO en font autant.

Du coup, c'est une donnée inexploitable que j'obtiens et pas possible de vérifier mes tables de routages :cry:

Va falloir que je trouve une autre solution.

Misssardonik a écrit :

Pas besoin d'un OS particulier pour ça, google suffit :D

Où avais-je la tête [:jsuistropcon]

Misssardonik

Pas besoin d'un OS particulier pour ça, google suffit :D

La valeur TTL 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.

(extrait de http://www.delafond.org/traducmanf [...] ing.8.html )

Si quelqu'un a un GNU/linux sous la main, est-ce qu'il pourrait faire un:
man ping > ~/ping.txt et le poster ici ?

Scr@t

Avec un titre comme celui la, je vais avoir des lecteurs en nombre :)
Alors salut à vous amis forumeurs

Mais j'aurais pas des masses de réponses je pense :cry:

En fait, ping, je connais et je sais l'utiliser.
Ma question est lié au TTL appliqués aux paquets envoyés.
Et c'est une info fournie par ping que je n'avais jamais utilisée.

Pour moi, le TTL (time to live), c'était juste une donnée de controle pour empécher les paquets d'encombrer le réseau en tournant en rond.
Lors de l'envoi du paquet, !'OS mets une valeur TTL assez elévé et retire 1 à chaque fois qu'il traverse un routeur et detruit le paquet si le TTL arrives à 0

Mais voila que mes "certitudes" viennent de s'écrouler.
J'ai aujourd'hui eut besoin d'utiliser cette donnée fournie par ping pour annalyser mes tables de routages et je ne comprends plus rien.

J'ai donc cherché à comprendre chez moi.
1 - ping 127.0.0.1 pour savoir quel est la valeur de base du TTL (128 sur Vista64)
2 - ping 192.168.1.254 (c'est mon routeur)

Et sur le ping du routeur, le paquet revient avec un TTL de 64 :ouch:
Comme je suis sur que le paquet n'a pas été traité plus de 2 fois, je m'attendais à le voir revenir avec un TTL de 126
Mais 64 :ouch:
Comme il n'a pas été traité 64 fois (et comme par le plus grand des hasard 64 = 128/2), je me dit que j'ai pas tout compris.

Alors amis lecteurs, il y a t'il un courageu parmi vous pour éclairer ma lanterne ?

Merci