OK. Now I understand what you are saying. Some systems, for better or for worse, set the TTL differently and this can be exploited to guess the system kernel, as discussed here:
http://www.geocrawler.com/archives/3...0/9/0/4279406/
Because, as the ping manpage says:
Quote:
The maximum possible value of this field is 255, and most Unix systems
set the TTL field of ICMP ECHO_REQUEST packets to 255. This is why you
will find you can ``ping'' some hosts, but not reach them with telnet(1)
or ftp(1).
In normal operation ping prints the ttl value from the packet it re-
ceives. When a remote system receives a ping packet, it can do one of
three things with the TTL field in its response:
o Not change it; this is what Berkeley Unix systems did before the
4.3BSD-Tahoe release. In this case the TTL value in the received
packet will be 255 minus the number of routers in the round-trip
path.
o Set it to 255; this is what current Berkeley Unix systems do. In
this case the TTL value in the received packet will be 255 minus the
number of routers in the path from the remote system to the pinging
host.
o Set it to some other value. Some machines use the same value for
ICMP packets that they use for TCP packets, for example either 30 or
60. Others may use completely wild values.
You want to change the behavior of a host receiving an ICMP_ECHO_REQUEST by altering the TTL set by the host.
Nice idea!!! There is value to this idea, thanks for pointing this out.
In linux, this value is defined in the
ip.h header file in the source distribution:
One way to change it is to modify the parameter in the
ip.h include file and rebuild the kernel.
However, different systems allow you to configure
MAXTTL from the command line or in a configuration file like
/etc/rc.d.
BTW. This was an EXCELLENT question. I tested two modern linux kernels (TTL, 255) and one Win98 system (TTL, 64).
10-03-2001
