Je suis encore sous W98 (ben oui, quand on peut peu !)
En effectuant : Ping www.voila.fr, j'observe un envoi avec TTL = 118
Pour vous, sur d'autres OS, avez-vous aussi la même valeur ? ce serait
intéressant de comparer.
Par contre, avec Ping www.google.fr, le TTL passe à 244.
Selon vous, comment ce TTL s'est-il trouvé modifié.
Merci pour vos avis, commentaires, remarques...
Cordialement,
Angelot
Je suis encore sous W98 (ben oui, quand on peut peu !)
En effectuant : Ping www.voila.fr, j'observe un envoi avec TTL = 118 Pour vous, sur d'autres OS, avez-vous aussi la même valeur ? ce serait intéressant de comparer.
Par contre, avec Ping www.google.fr, le TTL passe à 244. Selon vous, comment ce TTL s'est-il trouvé modifié.
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit. En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63, 127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a 11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118).
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY.
Le TTL vu depend de l'OS des machines en face, pas de la tienne. -- Thomas
Angelot wrote:
Bonjour,
Je suis encore sous W98 (ben oui, quand on peut peu !)
En effectuant : Ping www.voila.fr, j'observe un envoi avec TTL = 118
Pour vous, sur d'autres OS, avez-vous aussi la même valeur ? ce serait
intéressant de comparer.
Par contre, avec Ping www.google.fr, le TTL passe à 244.
Selon vous, comment ce TTL s'est-il trouvé modifié.
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit.
En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63,
127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur
equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a
11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118).
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a
des subtilités dans la forme de l'ECHO REPLY.
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
--
Thomas
Je suis encore sous W98 (ben oui, quand on peut peu !)
En effectuant : Ping www.voila.fr, j'observe un envoi avec TTL = 118 Pour vous, sur d'autres OS, avez-vous aussi la même valeur ? ce serait intéressant de comparer.
Par contre, avec Ping www.google.fr, le TTL passe à 244. Selon vous, comment ce TTL s'est-il trouvé modifié.
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit. En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63, 127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a 11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118).
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY.
Le TTL vu depend de l'OS des machines en face, pas de la tienne. -- Thomas
Jacques Caron
Salut,
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut <thomas@parinux.org>
wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu,
non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Angelot
Merci Thomas,
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit. En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63, 127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a 11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118). Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Votre explication est limpide, merci de la précision.
Par tracert www.voila.fr je trouve bien les 10 sauts correspondants aux 9 routeurs (problème de piquets et d'intervalles).
Par tracert www.google.fr par contre, on trouve 14 ou 15 lignes de résultats mais ça coince au 13ème saut, lequel est noté curieusement : unknown.Level3.net [64.156.240.26]. Mais, si je fais le ping de ce 13ème saut, je trouve TTL = 243.
On remarque donc :
Le ping de destination finale de google.fr donne 10 sauts Le ping d'une destination intermédiaire donnée par tracert de google.fr donne plus de 10 sauts.
Bon ! les chemins semblent différents.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY.
Je note, et ne connais pas encore
Cordialement, Angelot
Merci Thomas,
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit.
En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63,
127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur
equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a
11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118).
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Votre explication est limpide, merci de la précision.
Par tracert www.voila.fr je trouve bien les 10 sauts correspondants aux 9
routeurs (problème de piquets et d'intervalles).
Par tracert www.google.fr par contre, on trouve 14 ou 15 lignes de résultats
mais ça coince au 13ème saut, lequel est noté curieusement :
unknown.Level3.net [64.156.240.26]. Mais, si je fais le ping de ce 13ème
saut, je trouve TTL = 243.
On remarque donc :
Le ping de destination finale de google.fr donne 10 sauts
Le ping d'une destination intermédiaire donnée par tracert de google.fr
donne plus de 10 sauts.
Bon ! les chemins semblent différents.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a
des subtilités dans la forme de l'ECHO REPLY.
Le TTL que tu vois, est le TTL de l'ECHO REPLY que tu recoit. En fonction des OS, la stack IP renvoit un ECHO REPLY avec un TTL de 63, 127 ou 255 au moment de l'emission. Ensuite ce TTL est abaissé d'un paur equipement routant traversé.
Les serveurs de google renvoient donc un TTL de 255, ils doivent être a 11 "sauts" de ta machine, ceux de voila, à 9 sauts (127 - 118). Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Votre explication est limpide, merci de la précision.
Par tracert www.voila.fr je trouve bien les 10 sauts correspondants aux 9 routeurs (problème de piquets et d'intervalles).
Par tracert www.google.fr par contre, on trouve 14 ou 15 lignes de résultats mais ça coince au 13ème saut, lequel est noté curieusement : unknown.Level3.net [64.156.240.26]. Mais, si je fais le ping de ce 13ème saut, je trouve TTL = 243.
On remarque donc :
Le ping de destination finale de google.fr donne 10 sauts Le ping d'une destination intermédiaire donnée par tracert de google.fr donne plus de 10 sauts.
Bon ! les chemins semblent différents.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY.
Je note, et ne connais pas encore
Cordialement, Angelot
RAKOTOMALALA Renaud
Salut,
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
Jacques.
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes. Il s'applique à tout paquet quelqu'il soit. A chaque passage sur un routeur, le TTL est décrementé (cette fonciton est notamment utilisé pour effectuer un traceroute).
un TTL s'applique à un packet et non à une session, de ce fait lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la destination n'est pas jointe avant que le TTL fixé, le paquet est silencieusement annulé par le dernier routeur.
Plus on augmente le TTL plus le temps estimé avant de considéré un paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc moins le flux sera rapide. Plus le TTL sera petit et plus la detection pourra être rapide, avec l'inconvenient d'avoir un TTL trop petit, est la possibilité de ne jamais pouvoir atteindre la destination.
Par exemple si l'hote se toruve sur le LAN il ne sert à rien de mettre le TTL d'un paquet à 244 puisque l'on peut estimer qu'à cette distance ca ne sera plus le LAN.
Dans le cas d'origine le système estime probablement la distance pour joindre l'autre au moyen d'algo ou autre.
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut
<thomas@parinux.org> wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL
reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux
machines...
Jacques.
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes.
Il s'applique à tout paquet quelqu'il soit. A chaque passage sur un
routeur, le TTL est décrementé (cette fonciton est notamment utilisé
pour effectuer un traceroute).
un TTL s'applique à un packet et non à une session, de ce fait
lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la
destination n'est pas jointe avant que le TTL fixé, le paquet est
silencieusement annulé par le dernier routeur.
Plus on augmente le TTL plus le temps estimé avant de considéré un
paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc
moins le flux sera rapide. Plus le TTL sera petit et plus la detection
pourra être rapide, avec l'inconvenient d'avoir un TTL trop petit, est
la possibilité de ne jamais pouvoir atteindre la destination.
Par exemple si l'hote se toruve sur le LAN il ne sert à rien de mettre
le TTL d'un paquet à 244 puisque l'on peut estimer qu'à cette distance
ca ne sera plus le LAN.
Dans le cas d'origine le système estime probablement la distance pour
joindre l'autre au moyen d'algo ou autre.
On Tue, 22 Jun 2004 16:01:30 +0100, Thomas Pedoussaut wrote:
Le TTL vu depend de l'OS des machines en face, pas de la tienne.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
Jacques.
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes. Il s'applique à tout paquet quelqu'il soit. A chaque passage sur un routeur, le TTL est décrementé (cette fonciton est notamment utilisé pour effectuer un traceroute).
un TTL s'applique à un packet et non à une session, de ce fait lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la destination n'est pas jointe avant que le TTL fixé, le paquet est silencieusement annulé par le dernier routeur.
Plus on augmente le TTL plus le temps estimé avant de considéré un paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc moins le flux sera rapide. Plus le TTL sera petit et plus la detection pourra être rapide, avec l'inconvenient d'avoir un TTL trop petit, est la possibilité de ne jamais pouvoir atteindre la destination.
Par exemple si l'hote se toruve sur le LAN il ne sert à rien de mettre le TTL d'un paquet à 244 puisque l'on peut estimer qu'à cette distance ca ne sera plus le LAN.
Dans le cas d'origine le système estime probablement la distance pour joindre l'autre au moyen d'algo ou autre.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
J'ai sorti mon Ethereal que j'aurais dû d'ailleurs mettre en route avant de poser cette question.
Mon Ping request (pour W98) est toujours réalisé avec TTL = 32. Donc, pour 2 cas, je n'observe pas de mécanisme de recopie. Je constate au passage que les requêtes TCP et HTTP s'effectuent avec TTL 128 pour IP, avec des réponses TTL entre 40 et 43.
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Cordialement, Angelot
Bonjour Jacques,
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu,
non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
J'ai sorti mon Ethereal que j'aurais dû d'ailleurs mettre en route avant de
poser cette question.
Mon Ping request (pour W98) est toujours réalisé avec TTL = 32. Donc, pour 2
cas, je n'observe pas de mécanisme de recopie.
Je constate au passage que les requêtes TCP et HTTP s'effectuent avec TTL 128 pour IP, avec des réponses TTL entre 40 et 43.
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi
d'une charge utile provenant de la couche transport.
Il me semble que certains OS répondent aux pings en recopiant le TTL reçu, non? Dans ce cas, le TTL reçu en réponse dépendrait des deux machines...
J'ai sorti mon Ethereal que j'aurais dû d'ailleurs mettre en route avant de poser cette question.
Mon Ping request (pour W98) est toujours réalisé avec TTL = 32. Donc, pour 2 cas, je n'observe pas de mécanisme de recopie. Je constate au passage que les requêtes TCP et HTTP s'effectuent avec TTL 128 pour IP, avec des réponses TTL entre 40 et 43.
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Cordialement, Angelot
Jacques Caron
Salut,
On Tue, 22 Jun 2004 17:40:30 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes.
Je ne sais pas ce que c'est qu'un paquet fantôme, mais le TTL sert à éviter les boucles infinies (paquet qui serait renvoyé indéfiniment entre deux routeurs à cause d'un problème de routage en boucle).
un TTL s'applique à un packet et non à une session, de ce fait lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la destination n'est pas jointe avant que le TTL fixé, le paquet est silencieusement annulé par le dernier routeur.
Non, pas silencieusement. Il émet un ICMP "TTL exceeded".
Plus on augmente le TTL plus le temps estimé avant de considéré un paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc moins le flux sera rapide.
Non, absolument aucun rapport. Le TTL n'est qu'un nombre de sauts maximum pour un paquet. Le timeout pour réémission (qui dépend du protocole supérieur) est totalement indépendant. Et en l'absence de pertes de paquets, c'est la taille de la fenêtre et la latence aller-retour totale qui dictent le débit maximal d'une connexion TCP (par exemple). Un protocole sans windowing serait affecté uniquement par la latence aller-retour.
Ceci dit, rien dans ce que vous dites ne contredit le fait qu'un OS puisse recopier le TTL d'un paquet ICMP ECHO REQUEST reçu dans le paquet ICMP ECHO REPLY renvoyé en retour...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 22 Jun 2004 17:40:30 +0200, RAKOTOMALALA Renaud
<renaud+news@w-consulting.fr> wrote:
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes.
Je ne sais pas ce que c'est qu'un paquet fantôme, mais le TTL sert à
éviter les boucles infinies (paquet qui serait renvoyé indéfiniment entre
deux routeurs à cause d'un problème de routage en boucle).
un TTL s'applique à un packet et non à une session, de ce fait
lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la
destination n'est pas jointe avant que le TTL fixé, le paquet est
silencieusement annulé par le dernier routeur.
Non, pas silencieusement. Il émet un ICMP "TTL exceeded".
Plus on augmente le TTL plus le temps estimé avant de considéré un
paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc
moins le flux sera rapide.
Non, absolument aucun rapport. Le TTL n'est qu'un nombre de sauts maximum
pour un paquet. Le timeout pour réémission (qui dépend du protocole
supérieur) est totalement indépendant. Et en l'absence de pertes de
paquets, c'est la taille de la fenêtre et la latence aller-retour totale
qui dictent le débit maximal d'une connexion TCP (par exemple). Un
protocole sans windowing serait affecté uniquement par la latence
aller-retour.
Ceci dit, rien dans ce que vous dites ne contredit le fait qu'un OS puisse
recopier le TTL d'un paquet ICMP ECHO REQUEST reçu dans le paquet ICMP
ECHO REPLY renvoyé en retour...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 22 Jun 2004 17:40:30 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Le TTL est une fonctionnalité qui permet d'eviter des packets fantomes.
Je ne sais pas ce que c'est qu'un paquet fantôme, mais le TTL sert à éviter les boucles infinies (paquet qui serait renvoyé indéfiniment entre deux routeurs à cause d'un problème de routage en boucle).
un TTL s'applique à un packet et non à une session, de ce fait lorsqu'une machine emet un paquet, celle-ci lui fixe un TTL, si la destination n'est pas jointe avant que le TTL fixé, le paquet est silencieusement annulé par le dernier routeur.
Non, pas silencieusement. Il émet un ICMP "TTL exceeded".
Plus on augmente le TTL plus le temps estimé avant de considéré un paquet comme perdu (si il n'a pas été accusé (ACK)) est long, et donc moins le flux sera rapide.
Non, absolument aucun rapport. Le TTL n'est qu'un nombre de sauts maximum pour un paquet. Le timeout pour réémission (qui dépend du protocole supérieur) est totalement indépendant. Et en l'absence de pertes de paquets, c'est la taille de la fenêtre et la latence aller-retour totale qui dictent le débit maximal d'une connexion TCP (par exemple). Un protocole sans windowing serait affecté uniquement par la latence aller-retour.
Ceci dit, rien dans ce que vous dites ne contredit le fait qu'un OS puisse recopier le TTL d'un paquet ICMP ECHO REQUEST reçu dans le paquet ICMP ECHO REPLY renvoyé en retour...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
T0t0
"Angelot" wrote in message news:cb9jr5$jpc$
Le ping de destination finale de google.fr donne 10 sauts Le ping d'une destination intermédiaire donnée par tracert de google.fr donne plus de 10 sauts.
Le TTL ne peut en aucun cas être une valeur exacte pour valider le nombre de sauts. Comme le dit Renaud, c'est une valeur simplement liée au routage pour éviter les boucles. Elle peut aussi servir dans le cas de traceroute en détournant sa fonction initiale. <http://www.lalitte.com/reseau.html#tracert> Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer le nombre de sauts intermédiaires, car on ne connait pas alors la valeur de TTL initialisée par la machine en face, ni par les machines intermédiaires qui peuvent la modifier.
Bon ! les chemins semblent différents.
Vu que le routage se fait par l'adresse destination, ca ne me choque pas. Ca dépend à mon avis en grande partie des accords de peering des ISP et du routage mis en place.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY. Je note, et ne connais pas encore
Vu que certains OS répondent avec un certain TTL, en évaluant le nombre de hop jusqu'à une destination et le TTL reçu, on peut déterminer à peu près le TTL d'origine qui est une des caractéristiques d'un système. En recoupant avec d'autres infos, on arrive à avoir une idée précise du système en face, même s'il n'a pas de ports ouverts ;-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cb9jr5$jpc$1@news-reader4.wanadoo.fr
Le ping de destination finale de google.fr donne 10 sauts
Le ping d'une destination intermédiaire donnée par tracert de google.fr
donne plus de 10 sauts.
Le TTL ne peut en aucun cas être une valeur exacte pour valider le
nombre de sauts. Comme le dit Renaud, c'est une valeur simplement liée
au routage pour éviter les boucles. Elle peut aussi servir dans le
cas de traceroute en détournant sa fonction initiale.
<http://www.lalitte.com/reseau.html#tracert>
Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer
le nombre de sauts intermédiaires, car on ne connait pas alors la valeur
de TTL initialisée par la machine en face, ni par les machines
intermédiaires qui peuvent la modifier.
Bon ! les chemins semblent différents.
Vu que le routage se fait par l'adresse destination, ca ne me choque
pas. Ca dépend à mon avis en grande partie des accords de peering des
ISP et du routage mis en place.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a
des subtilités dans la forme de l'ECHO REPLY.
Je note, et ne connais pas encore
Vu que certains OS répondent avec un certain TTL, en évaluant le nombre
de hop jusqu'à une destination et le TTL reçu, on peut déterminer à
peu près le TTL d'origine qui est une des caractéristiques d'un
système. En recoupant avec d'autres infos, on arrive à avoir une idée
précise du système en face, même s'il n'a pas de ports ouverts ;-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Le ping de destination finale de google.fr donne 10 sauts Le ping d'une destination intermédiaire donnée par tracert de google.fr donne plus de 10 sauts.
Le TTL ne peut en aucun cas être une valeur exacte pour valider le nombre de sauts. Comme le dit Renaud, c'est une valeur simplement liée au routage pour éviter les boucles. Elle peut aussi servir dans le cas de traceroute en détournant sa fonction initiale. <http://www.lalitte.com/reseau.html#tracert> Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer le nombre de sauts intermédiaires, car on ne connait pas alors la valeur de TTL initialisée par la machine en face, ni par les machines intermédiaires qui peuvent la modifier.
Bon ! les chemins semblent différents.
Vu que le routage se fait par l'adresse destination, ca ne me choque pas. Ca dépend à mon avis en grande partie des accords de peering des ISP et du routage mis en place.
C'est un des mechanismes utilisés pour le fingerprinting des OS, il y a des subtilités dans la forme de l'ECHO REPLY. Je note, et ne connais pas encore
Vu que certains OS répondent avec un certain TTL, en évaluant le nombre de hop jusqu'à une destination et le TTL reçu, on peut déterminer à peu près le TTL d'origine qui est une des caractéristiques d'un système. En recoupant avec d'autres infos, on arrive à avoir une idée précise du système en face, même s'il n'a pas de ports ouverts ;-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
T0t0
"Angelot" wrote in message news:cb9l8i$m7l$
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante. A priori, je dirais que c'est la couche IP qui gère l'envoi de ces paquets, quel que soit le protocole sup (ICMP, UDP ou TCP) Or ce résultat semble le contredire...
Plus d'infos là dessus ?
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cb9l8i$m7l$1@news-reader4.wanadoo.fr
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi
d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante.
A priori, je dirais que c'est la couche IP qui gère l'envoi de ces
paquets, quel que soit le protocole sup (ICMP, UDP ou TCP)
Or ce résultat semble le contredire...
Plus d'infos là dessus ?
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante. A priori, je dirais que c'est la couche IP qui gère l'envoi de ces paquets, quel que soit le protocole sup (ICMP, UDP ou TCP) Or ce résultat semble le contredire...
Plus d'infos là dessus ?
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Angelot
Bonsoir T0t0,
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante. A priori, je dirais que c'est la couche IP qui gère l'envoi de ces paquets, quel que soit le protocole sup (ICMP, UDP ou TCP) Or ce résultat semble le contredire...
Plus d'infos là dessus ?
J'ai peine à dire que toute charge utile d'un datagramme provient d'une couche supérieure : ICMP est de même niveau qu'IP. Il existe d'autre cas similaires : OSPF ou ESP
Angelot
Bonsoir T0t0,
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi
d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante.
A priori, je dirais que c'est la couche IP qui gère l'envoi de ces
paquets, quel que soit le protocole sup (ICMP, UDP ou TCP)
Or ce résultat semble le contredire...
Plus d'infos là dessus ?
J'ai peine à dire que toute charge utile d'un datagramme provient d'une
couche supérieure : ICMP est de même niveau qu'IP. Il existe d'autre cas
similaires : OSPF ou ESP
En tous cas, le TTL d'envoi du ping n'est pas le même que le TTL d'envoi d'une charge utile provenant de la couche transport.
Ca c'est une info très intéressante. A priori, je dirais que c'est la couche IP qui gère l'envoi de ces paquets, quel que soit le protocole sup (ICMP, UDP ou TCP) Or ce résultat semble le contredire...
Plus d'infos là dessus ?
J'ai peine à dire que toute charge utile d'un datagramme provient d'une couche supérieure : ICMP est de même niveau qu'IP. Il existe d'autre cas similaires : OSPF ou ESP
Angelot
Angelot
Re T0t0,
Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer le nombre de sauts intermédiaires, car on ne connait pas alors la valeur de TTL initialisée par la machine en face
Les valeurs d'origine ne sont pas si nombreuses que cela. Comme Thomas l'a indiqué, on peut supputer des valeurs initiales telles que 32, 63 ou 64, 127 ou 128, 255. Cela donne une bonne idée sachant que l'on dépasse rarement 30 routeurs.
Cordialement, Angelot
Re T0t0,
Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer
le nombre de sauts intermédiaires, car on ne connait pas alors la valeur
de TTL initialisée par la machine en face
Les valeurs d'origine ne sont pas si nombreuses que cela. Comme Thomas l'a
indiqué, on peut supputer des valeurs initiales telles que 32, 63 ou 64, 127
ou 128, 255. Cela donne une bonne idée sachant que l'on dépasse rarement 30
routeurs.
Mais on ne peut pas se baser sur la valeur de TTL reçu pour imaginer le nombre de sauts intermédiaires, car on ne connait pas alors la valeur de TTL initialisée par la machine en face
Les valeurs d'origine ne sont pas si nombreuses que cela. Comme Thomas l'a indiqué, on peut supputer des valeurs initiales telles que 32, 63 ou 64, 127 ou 128, 255. Cela donne une bonne idée sachant que l'on dépasse rarement 30 routeurs.
