On Wednesday 20 July 2005 09:55, Toshi Esumi wrote:
On Wed, 2005-07-20 at 04:47 +0200, Anders Johansson wrote:
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies?
Yeah, but it doesn't have to mean anything, since as I mentioned, not all sites respond to ICMP packets, and traceroute uses ICMP to do its thing
Actually, "traceroute" (at least on Unix/Linux machines) uses UDP packets to find out hops in between utilizing TTL. Not ICMP packets.
It uses both. When a packet's time to live has been exceeded, the remote host is supposed to send ICMP TTL EXCEEDED, and that is what traceroute uses to discover the path the packets take There cam be a number of reasons why you get the * * * in the traceroute output, but firewall blocking should not be one of them, except perhaps in the last hop. Since it's not the final destination, a router on the internet that blocks packets would disrupt a great amount of internet traffic on its path. Some routers simply block all ICMP traffic, which would include the ICMP TTL EXCEEDED packets. And apparently some older, broken routers use the same TTL in the response ICMP packet as the original packet that caused the timeout, which of course means it's not going anywhere, since it's already timed out. In both cases, you get the * * *
http://www.private.org.il/mini-tcpip.faq.html#1.%20Of%20ping%20&% 20traceroute.
Therefore, in my understanding, if there is a FW inbetween that doesn't allow any high port UDP packets (over port 33434 by default) to go though,
As I said, since they're not the final destination, any router that does this has no business being a public router in the first place. And it wouldn't be for very long, it would disrupt too much traffic along its path