The question was "But, I don't understand, how the traceroute works when
the host is up, but when the host is down it times out???" and remarked on
the 30 lines of output in a time out situation.
Although I cited Fedora 8 as the page I was quoting, the traceroute
documentation for most any modern distro contains the explanation about
the 30-hop default and the behavior when the tracerouted host is not
reached. Sorry if I wasn't clear.
On Mon, January 14, 2008 13:19, Josh Luthman wrote:
Then I don't see how the FC8 traceroute documentation would be relevant,
as Michael stated that he can do one from the shell but errors out in
Hobbit.
Am I missing something here?
On 1/14/08, Hobbit User in Richmond <user-24d6f8323faa@xymon.invalid>
wrote:
Presumably.
On Mon, January 14, 2008 12:40, Josh Luthman wrote:
Wouldn't the traceroute used by Hobbit be the same command as the
shell?
On 1/14/08, Hobbit User in Richmond <user-24d6f8323faa@xymon.invalid>
wrote:
Actually, ICMP echo-request and echo-reply packets are almost
certainly
not an issue here, nor is packet-filtering/firewalling. In current
implementations, traceroute by default uses UDP packets to
abitrary
and
unlikely-to-respond ports, varying the TTL and using the ICMP type
11
(Time Exceeded) from hops along the way to map the routing path.
The manpage in Fedora 8 says "We start our probes with a ttl of one
and
increase by one until we...got to the "host", or hit a max (which
defaults to 30 hops)".
So, the behavior you're seeing is as documented. If a firewall
were
an
issue in sending/receiving the packets used by traceroute, you'd
see the 30-hop behavior whether the host was up or down.
On Mon, January 14, 2008 11:17, Michael A. Price wrote:
Josh,
Thanks for helping... The source/destination is on a closed
network, sorry...and I don't own the router...
But, I don't understand, how the traceroute works when the host
is up, but when the host is down it times out???
If it works when the host is up, then you would think the ACL on
%