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 <hobbit at epperson.homelinux.net> 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 <hobbit at epperson.homelinux.net> 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 %