>> >> I'd like to change the default maxttl from 30 to
>> >> 64 (this matches the kernel default ttl too).  Apart from causing longer
>> >> reports when packets go in circles, can anyone see a reason not to bump
>> >> this up ?
>> >
>> >Ping has long used a TTL of 255.  Why not do something similar for
>> >traceroute?  To prevent one from seeing 200+ failure lines traceroute
>> >could simply stop upping the ttl whenever the past N TTL settings
>> >failed.  (Eg. if the past 5-10 traceroute TTL's didn't get a reply,
>> >stop incrementing the TTL and exit.)
>
>I don't want to change the behaviour of traceroute (as this suggests),
>only its defaults.  Behavioural changes like that are more likely to
>have some sort of ripple effect god knows where.

...like traceroute not bothering to actually reach the target due to
too many hops in between dropping packets for some reason.

>> the difference between ping and traceroute is that ping starts off by
>> attempting to "get there", whereas traceroute starts off by assuming
>> it can't.
>
>This comment got me thinking.  What is the point of ping being able to
>'get there' if (for example) ssh can't ?

ping usually gets an immediate response.  or not.  ssh take a little
longer.  ping can also print out the intermediate "host or network not
reachable" messages that it might get back.  ssh can't.

>If a ttl of 255 is good enough for ping, why not change net.inet.ip.ttl
>to 255 as well ?

*shrug*

>The more I think about it, the more sense it makes to tune traceroute to
>net.inet.ip.ttl because when "ssh cvs.netbsd.org" doesn't work, 9 times
>out of 10 you are going to see what traceroute does and for traceroute to
>return meaningful results, it should be using the same ttl as ssh, right?

well...yes and no.  if ping can't get there, traceroute might also not
be able to get there, but for different reasons, and different reasons
from ssh.  traceroute typically uses high numbered destination udp
ports.  ping uses icmp echo requests.  both of these are easy to block
at any point along the way.

if you *really* want to try to test the path that ssh takes, you'd do
this:

	hping -n -T -S -p 22 cvs.netbsd.org

that'd really give you a much better idea of what ssh was
experiencing.  otoh, there's mtr which gives a much better view of the
current routing path because it does all its probes in parallel.

>I don't understand why we should bother to have the default ttl different
>to what's in ping (or the other way around).

i think it makes little difference, unless you were to lower the
default ttl for ping to lower than that of the system in general.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."