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
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 ;-)
Tu as raison, cela fait partie des méthodes pour reconnaitre un OS distant. Certaine méthodes se basent aussi : - Sur les numéros de sequence, comme un OS bien connu qui est en mode incrémentiel. :) - La taille par défaut de la sliding windows - Le non respect des Rfc comme, le même OS, qui à tendence à répondre un FIN/ACK :) - La conformité des paquets Icmp d'erreurs retournés
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
"T0t0" <bibi@antionline.org> a écrit dans le message de news:
227d2942da3840d33b400508fef3620d.28089@mygate.mailgate.org...
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cb9jr5$jpc$1@news-reader4.wanadoo.fr
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 ;-)
Tu as raison, cela fait partie des méthodes pour reconnaitre un OS distant.
Certaine méthodes se basent aussi :
- Sur les numéros de sequence, comme un OS bien connu qui est en mode
incrémentiel. :)
- La taille par défaut de la sliding windows
- Le non respect des Rfc comme, le même OS, qui à tendence à répondre un
FIN/ACK :)
- La conformité des paquets Icmp d'erreurs retournés
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 ;-)
Tu as raison, cela fait partie des méthodes pour reconnaitre un OS distant. Certaine méthodes se basent aussi : - Sur les numéros de sequence, comme un OS bien connu qui est en mode incrémentiel. :) - La taille par défaut de la sliding windows - Le non respect des Rfc comme, le même OS, qui à tendence à répondre un FIN/ACK :) - La conformité des paquets Icmp d'erreurs retournés
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
_SebF - www.frameip.com
"Angelot" a écrit dans le message de 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.
La gestion du TTL est effectuée au niveau 3. Ma remarque est que la gestion dépend du système d'exploitation qui est chargé du fonctionnement des différentes couches.
Donc à ce stade, on en déduit que cela dépend de l'OS. Mais partons sur une application qui gère elle même la couche Internet :-), alors c'est cette même application qui va décider du TTL indépendamment de l'OS.
Il est donc possible que ton application via Tcp, format les paquet au niveau IP.
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...) permettant de demander à la pile IP de l'OS de spécifier un TTL.
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de 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.
La gestion du TTL est effectuée au niveau 3. Ma remarque est que la gestion
dépend du système d'exploitation qui est chargé du fonctionnement des
différentes couches.
Donc à ce stade, on en déduit que cela dépend de l'OS. Mais partons sur une
application qui gère elle même la couche Internet :-), alors c'est cette
même application qui va décider du TTL indépendamment de l'OS.
Il est donc possible que ton application via Tcp, format les paquet au
niveau IP.
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...)
permettant de demander à la pile IP de l'OS de spécifier un TTL.
"Angelot" a écrit dans le message de 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.
La gestion du TTL est effectuée au niveau 3. Ma remarque est que la gestion dépend du système d'exploitation qui est chargé du fonctionnement des différentes couches.
Donc à ce stade, on en déduit que cela dépend de l'OS. Mais partons sur une application qui gère elle même la couche Internet :-), alors c'est cette même application qui va décider du TTL indépendamment de l'OS.
Il est donc possible que ton application via Tcp, format les paquet au niveau IP.
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...) permettant de demander à la pile IP de l'OS de spécifier un TTL.
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
Angelot
Bonsoir Seb,
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...) permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de service qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo])
Cordialement, Angelot
Bonsoir Seb,
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...)
permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de service
qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon,
compteur, PUSH, URGENT [, tempo])
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...) permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de service qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo])
Cordialement, Angelot
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news: cb9ue4$6to$
Bonsoir Seb,
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...)
permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de service
qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo])
Les commandes Send ou Sendto ne possèdent pas cette information. Cependant, le positionnement de l'option IP_TTL via la fonction SetSockOpt permet tout de même de spécifier le TTL.
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de news:
cb9ue4$6to$1@news-reader2.wanadoo.fr...
Bonsoir Seb,
Une autre idée : En dev, il existe la fonction
setSockOpt(...,IP_TTL,...)
permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de
service
qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon,
compteur, PUSH, URGENT [, tempo])
Les commandes Send ou Sendto ne possèdent pas cette information. Cependant,
le positionnement de l'option IP_TTL via la fonction SetSockOpt permet tout
de même de spécifier le TTL.
"Angelot" a écrit dans le message de news: cb9ue4$6to$
Bonsoir Seb,
Une autre idée : En dev, il existe la fonction setSockOpt(...,IP_TTL,...)
permettant de demander à la pile IP de l'OS de spécifier un TTL.
La couche TCP passe l'unité SDU à la couche IP par une primitive de service
qui ne comporte pas TTL en argument : SEND (nom_local, adresse_tampon, compteur, PUSH, URGENT [, tempo])
Les commandes Send ou Sendto ne possèdent pas cette information. Cependant, le positionnement de l'option IP_TTL via la fonction SetSockOpt permet tout de même de spécifier le TTL.
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
Angelot
Les commandes Send ou Sendto ne possèdent pas cette information. Cependant,
le positionnement de l'option IP_TTL via la fonction SetSockOpt permet tout
de même de spécifier le TTL.
OK Sèb !
Angelot
Les commandes Send ou Sendto ne possèdent pas cette information.
Cependant,
le positionnement de l'option IP_TTL via la fonction SetSockOpt permet
tout
Les commandes Send ou Sendto ne possèdent pas cette information. Cependant,
le positionnement de l'option IP_TTL via la fonction SetSockOpt permet tout
de même de spécifier le TTL.
OK Sèb !
Angelot
RAKOTOMALALA Renaud
Bonsoir,
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
Oui c'est exactement celà, je parle de fantome car il reste sur le réseau sans raison et donc en elargissant, on peut voir une boucle oui.
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...
Après t'avoir relu tu as totalement raison, j'aurais mieux fait de me relir avant de sortir des betises pareil. Ceci dit pour repondre à ta question lorsque l'on repond à quelqu'un ce n'est pas forcement pour contre-dire, on peut aussi vouloir apporter simplement des precisions ou autre.
Dans le cas présent mes precisions etaient totalement erroné.
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
Oui c'est exactement celà, je parle de fantome car il reste sur le
réseau sans raison et donc en elargissant, on peut voir une boucle oui.
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...
Après t'avoir relu tu as totalement raison, j'aurais mieux fait de me
relir avant de sortir des betises pareil. Ceci dit pour repondre à ta
question lorsque l'on repond à quelqu'un ce n'est pas forcement pour
contre-dire, on peut aussi vouloir apporter simplement des precisions ou
autre.
Dans le cas présent mes precisions etaient totalement erroné.
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
Oui c'est exactement celà, je parle de fantome car il reste sur le réseau sans raison et donc en elargissant, on peut voir une boucle oui.
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...
Après t'avoir relu tu as totalement raison, j'aurais mieux fait de me relir avant de sortir des betises pareil. Ceci dit pour repondre à ta question lorsque l'on repond à quelqu'un ce n'est pas forcement pour contre-dire, on peut aussi vouloir apporter simplement des precisions ou autre.
Dans le cas présent mes precisions etaient totalement erroné.
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... 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.
Tout à fait, je parlais de protocole sup car c'est parfois comme cela qu'est appelé le champ protocole de l'en-tête IP. "This field indicates the next level protocol used in the data portion of the internet datagram." Après, c'est une appréciation du terme "next level"
Mais tu as raison de le souligner, cela n'a pas de rapport avec la couche du protocole encapsulé :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cb9n3b$ou8$1@news-reader4.wanadoo.fr
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...
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.
Tout à fait, je parlais de protocole sup car c'est parfois comme cela
qu'est appelé le champ protocole de l'en-tête IP.
"This field indicates the next level protocol used in the data
portion of the internet datagram."
Après, c'est une appréciation du terme "next level"
Mais tu as raison de le souligner, cela n'a pas de rapport avec la
couche
du protocole encapsulé :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
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... 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.
Tout à fait, je parlais de protocole sup car c'est parfois comme cela qu'est appelé le champ protocole de l'en-tête IP. "This field indicates the next level protocol used in the data portion of the internet datagram." Après, c'est une appréciation du terme "next level"
Mais tu as raison de le souligner, cela n'a pas de rapport avec la couche du protocole encapsulé :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
