returned packets have ttl set to 255,128,64.. OS-dependant.. huh ?
horu...@my-dejanews.com
returned from some boxes running different OS's. The boxes are
all on my local network (traceroute shows 1 hop).
Here's a thorough explanation of the problem. This might be
long, but it's better asking a long question that makes sense
than asking a short question that doesn't make sense or a short
question whose answer is "Go buy some book on it and read it"
(like: "What is Unix ?).
Anyway, here's what happens:
=========================================================
Pinging a SCO box:
[horus@hermine] /home/horus>ping 10.20.10.7 -c 2
PING 10.20.10.7 (10.20.10.7): 56 data bytes
64 bytes from 10.20.10.7: icmp_seq=0 ttl=255 time=1.0 ms
64 bytes from 10.20.10.7: icmp_seq=1 ttl=255 time=0.9 ms
--- 10.20.10.7 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/1.0 ms
=========================================================
Pinging a NT box:
[horus@hermine] /home/horus>ping 10.20.5.5 -c 2
PING 10.20.5.5 (10.20.5.5): 56 data bytes
64 bytes from 10.20.5.5: icmp_seq=0 ttl=128 time=0.7 ms
64 bytes from 10.20.5.5: icmp_seq=1 ttl=128 time=0.6 ms
--- 10.20.5.5 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.6/0.7 ms
=========================================================
Pinging localhost (127.0.0.1) (pinging myself thru lo0):
[horus@hermine] /home/horus>ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=1.4 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=1.2 ms
--- localhost ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.2/1.3/1.4 ms
=========================================================
Pinging my Linux box (pinging myself, but thru eth0, not lo0):
[horus@hermine] /home/horus>ping hermine -c 2
PING hermine (10.20.10.13): 56 data bytes
64 bytes from 10.20.10.13: icmp_seq=0 ttl=64 time=1.3 ms
64 bytes from 10.20.10.13: icmp_seq=1 ttl=64 time=1.2 ms
--- hermine ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.2/1.2/1.3 ms
=========================================================
Pinging a box running RedHat/Sparc on a Sun Sparc IPX:
[horus@hermine] /home/horus>ping bazar -c 2
PING bazar (10.20.10.15): 56 data bytes
64 bytes from 10.20.10.15: icmp_seq=0 ttl=64 time=0.8 ms
64 bytes from 10.20.10.15: icmp_seq=1 ttl=64 time=0.7 ms
--- bazar ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.7/0.7/0.8 ms
=========================================================
Pinging a box running Solaris 7 on a Sun Sparc IPX:
[horus@hermine] /home/horus>ping ra -c 2
PING ra (10.20.10.14): 56 data bytes
64 bytes from 10.20.10.14: icmp_seq=0 ttl=255 time=0.7 ms
64 bytes from 10.20.10.14: icmp_seq=1 ttl=255 time=0.7 ms
--- ra ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.7/0.7/0.7 ms
=========================================================
All those machines are on the same local network. I mean,
the packets do not need to be routed when going from my box
to other boxes. In other words, the hop count is 1 in
traceroute:
[horus@hermine] /home/horus>traceroute 10.20.10.7
traceroute to 10.20.10.7 (10.20.10.7), 30 hops max, 40 byte packets
1 10.20.10.7 (10.20.10.7) 5.002 ms 4.424 ms 25.643 ms
[horus@hermine] /home/horus>traceroute 10.20.5.5
traceroute to 10.20.5.5 (10.20.5.5), 30 hops max, 40 byte packets
1 10.20.5.5 (10.20.5.5) 4.677 ms 6.413 ms 4.245 ms
[horus@hermine] /home/horus>traceroute localhost
traceroute to localhost (127.0.0.1), 30 hops max, 40 byte packets
1 localhost (127.0.0.1) 1.469 ms 0.759 ms 0.713 ms
[horus@hermine] /home/horus>traceroute hermine
traceroute to hermine (10.20.10.13), 30 hops max, 40 byte packets
1 hermine (10.20.10.13) 1.483 ms 0.791 ms 0.734 ms
[horus@hermine] /home/horus>traceroute bazar
traceroute to bazar (10.20.10.15), 30 hops max, 40 byte packets
1 bazar (10.20.10.15) 1.028 ms 0.706 ms 0.699 ms
[horus@hermine] /home/horus>traceroute ra
traceroute to ra (10.20.10.14), 30 hops max, 40 byte packets
1 ra (10.20.10.14) 2.057 ms * 1.918 ms ²
=========================================================
You will notice that the ttl (time to live) of the packet comes
back with a value of 255 when pinging a SCO box or a Solaris 7 box,
128 when pinging a NT box and 64 when pinging a Linux box.
As far as I know, the ttl is a one-byte value (0 thru 255) that
indicates the time a tcp/ip packet should 'live'. The value
is supposed to start at 255 (I think so). If the value reaches
0, the package will be destroyed. Each host that passes the
packet over is supposed to decrease the value of ttl
by one unit, so if we assume a packet passes thru nine hops
to reach its destination, ttl should start at 255, and the 1st
hop will set the ttl to 254, then the 2nd to 253, and so on.
As far as I know, the ttl is useful when the setup of local or
wide network is somewhat wrong, and that packets turn into a
loop. If they do turn into a loop, their ttl will reach 0,
and they will be destroyed, and a icmp message saying
"TTL expired while in transit" will be sent to the
packet originator. (Is that right ?)
Now the question is: why is it that packets come back with a ttl
of 255, 128, or 64, depending of the OS that the box is running ?
I guess the answer is obviously not "It's your box that sets the
ttl to 255, 128, 64 when it sends the ping" because it would mean
that the Linux ping command sends different values of ttl depending
on the value of the destinator's ip-adress. This would be, in my humble
opinion, a complete non-sense and a lot of useless work in the ping
source code.
So I'm just wondering why the destinator's OS sets the ttl to 255,
128 or 64 .... any ideas ?
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Barry Margolin
<horu...@my-dejanews.com> wrote:
>As far as I know, the ttl is a one-byte value (0 thru 255) that
>indicates the time a tcp/ip packet should 'live'. The value
>is supposed to start at 255 (I think so). If the value reaches
That's where you went wrong. The initial value is a system-dependent, and
different operating systems have different defaults. On Unix you can
change it with a kernel configuration option, on Windows there's a Registry
setting.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
horu...@my-dejanews.com
Barry Margolin <bar...@bbnplanet.com> wrote:
> In article <7asf3m$mrr$1...@nnrp1.dejanews.com>,
> <horu...@my-dejanews.com> wrote:
> >indicates the time a tcp/ip packet should 'live'. The value
> >is supposed to start at 255 (I think so). If the value reaches
>
> That's where you went wrong. The initial value is a system-dependent, and
> different operating systems have different defaults. On Unix you can
> change it with a kernel configuration option, on Windows there's a Registry
> setting.
>
Yes, that is right. When you *send* a tcp-ip packet, the ttl might be set to
64,128,255, whatever, depending of the operating system. But, I am sending
from the same OS all the time (RedHat 5.1 Linux with a 2.0.35 kernel), and I
was wondering why the machines who *replied* to my packets set the ttl to
255,128,64 ... ?
Jon Snader
>
> In article <RujA2.63$tR5.4787@burlma1-snr2>,
>
> Yes, that is right. When you *send* a tcp-ip packet, the ttl might be set to
> 64,128,255, whatever, depending of the operating system. But, I am sending
> from the same OS all the time (RedHat 5.1 Linux with a 2.0.35 kernel), and I
> was wondering why the machines who *replied* to my packets set the ttl to
> 255,128,64 ... ?
>
If I remember your original post correctly, you were pinging a variety
of different operating systems from your Linux machine. The TTL does
not get ``turned around'' by the ICMP echo reply; rather it is set for
each datagram by the sender (the system replying to the ping in this
case). Thus it doesn't matter what the TTL is set to (given it's large
enought to reach the destination) in the echo request. The responder
will set its own TTL based on its default, independent of the incoming
TTL.
Jon Snader