Re: It is a astonishing circumstance about trace route....

• Previous message: Roberto: "ipp2p bridge in kernel 2.6.10"
• In reply to: Fva: "Re: It is a astonishing circumstance about trace route...."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 06 Aug 2005 15:25:11 -0500

In the Usenet newsgroup comp.os.linux.networking, in article
<dd0djm$knn$1@netnews.hinet.net>, Fva wrote:

>Yes, my data of tracing route resulted from TRACERT of windows system.
>but, I have ever done that tracing route to 59.121.187.199 on unix system
>and the TraceRoute didn't stop when ICMP packet arrive at destination.

That could easily be explained by the host having a firewall, or being
configured to ignore pings. All to common today.

>The TraceRoute displayed "time out" message after arriving at destination.
>Until I pressed Ctrl+C to terminate it.

As mentioned, the windoze version of traceroute uses ping. Many people
block ping because of abuse.

[compton ~]$ ping -c 2 59.121.187.199
PING 59.121.187.199 (59.121.187.199): 56 data bytes

--- 59.121.187.199 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
[compton ~]$ traceroute -f 15 -q 2 59.121.187.199
traceroute to 59.121.187.199 (59.121.187.199) from 0.0.0.0, 30 hops max, 38
byte packets
15 220-128-1-30.HINET-IP.hinet.net (220.128.1.30) 289.984 ms 288.562 ms
16 220-128-1-117.HINET-IP.hinet.net (220.128.1.117) 299.877 ms 288.660 ms
17 tp-s2-c76r6.router.hinet.net (211.22.34.213) 290.552 ms 288.630 ms
18 h25.s83.ts.hinet.net (168.95.83.25) 294.594 ms 289.267 ms
19 * *
20 * *
^C
[compton ~]$

The '*' characters - something is blocking ICMP (or the UDP packets that
this UNIX version of traceroute is using). Using a different tool, I see:

17 tp-s2-c76r6.router.hinet.net (211.22.34.213) 294.448 ms 288.684 ms
18 h25.s83.ts.hinet.net (168.95.83.25) 294.551 ms 288.659 ms
19 59-121-187-199.dynamic.hinet.net (59.121.187.199) [closed] 324.699 ms
 328.512 ms
[compton ~]$

So, it is there and alive running a firewall, possibly in addition to being
set to ignore pings. As mentioned up thread, who knows if this is the
same host you reported the problem with, as this _is_ a dynamic address.

>So,it is possible that destination host responded with a "TTL exceeded"
>rather than "echo reply".

See the man page for a UNIX version of traceroute for an explanation of
how it operates, and try to find a copy of "TCP/IP Illustrated Volume 1"
by W. Richard Stevens (Addison Wesley, ISBN 0-201-63346-9). The "time to
live exceeded in transit" message (ICMP Type 11 Code 0) should only occur
from the host that decrements the TTL to zero (and that host should drop
the packet), There was a broken network stack in the original 4.3BSD
(mentioned in the tcpdump man page) where it was passing packets with a
TTL of zero. NORMALLY, the _destination_ host doesn't look at the TTL
except when the packet arrives in fragments, however it could do so.
What error it should return is questionable, as neither error listed (see
RFC0792 pages 5 and 6) is suitable. Note that when traceroute does not
receive the port unreachable code (or the windoze version does NOT receive
the echo reply), it increments the TTL (up to the maximum selected) and
tries again. Thus, the "last" host receiving the packet will see the TTL
increase above a zero. Oh, and do read RFC1122, and note that there is
no _requirement_ for a router or gateway to decrement the TTL - that is
just the _normal_ implementation.

        Old guy

• Previous message: Roberto: "ipp2p bridge in kernel 2.6.10"
• In reply to: Fva: "Re: It is a astonishing circumstance about trace route...."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]