Description of problem:
traceroute may continue past destination host
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Run traceroute with dst host 188.8.131.52
$ traceroute 184.108.40.206
22 sl-bb23-sj-10-0.sprintlink.net (220.127.116.11) 211.476 ms sl-gw13-sj-9-
0.sprintlink.net (18.104.22.168) 202.982 ms 199.562 ms
23 sl-bbwl-4-0-0.sprintlink.net (22.214.171.124) 249.675 ms sl-gw13-sj-9-
0.sprintlink.net (126.96.36.199) 203.184 ms 200.161 ms
24 sl-bbwl-4-0-0.sprintlink.net (188.8.131.52) 219.684 ms 234.350 ms cpe-
24-221-130-104.az.sprintbbd.net (184.108.40.206) 403.839 ms
25 * cpe-24-221-130-104.az.sprintbbd.net (220.127.116.11) 341.973 ms
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
$ traceroute 18.104.22.168
22 sl-gw13-sj-9-0.sprintlink.net (22.214.171.124) 200.680 ms sl-bb23-sj-10-
0.sprintlink.net (126.96.36.199) 206.875 ms 212.309 ms
23 sl-gw13-sj-9-0.sprintlink.net (188.8.131.52) 208.670 ms 202.148 ms
24 cpe-24-221-130-104.az.sprintbbd.net (184.108.40.206) 316.045 ms 316.795
ms 317.416 ms
Created attachment 132630 [details]
Checked in, thanks a lot
Dan, Radek...was this fix also sent to upstream?
Will do so ..
I'm not sure this is a genuine bug in traceroute, it looks more like
a strange IP stack in that router to me. Apparently that router
decrements the TTL on every incoming packet before looking at it, which is
in violation of the RFCs (you're supposed to decrement it when forwarding).
On top of that, the router is apparently configured to just drop any
incoming UDP packet, so this means that instead of replying with a
DEST_UNREACH to the next packet that comes along, it just shuts up.
The patch you propose works around the problem, even though it seems a
bit of a hack to me. I'll think about how to do this.
Yes, it is obvious that the problem is the abnormal response from that
router. Originally I was solving this problem in tracepath and I
noticed that it behaves the same way. They both expect CONNREFUSED
upon reaching the target. This condition seems to me as very deficient
but I guess tracerouting is supposed to work this way. Information
about the origin of the response is available and probably we can't
have anything better. How the machine replies to us is easily changed
but the address stays. I don't see this modification as a hack but as
a feature traceroute should have. If not as default, then using a
specialized option. I can supply a new path which will add this
behaviour. Wouldn't this be more suitable?
Created attachment 134129 [details]
Fix - new option -c
It seems to be a corner case. It affects all three implementations of
traceroute, including original, Olaf's and mine. The host "220.127.116.11"
answers "time exceed", and then answers nothing. It is the reason why all
traceroutes do not stop on it (all them consider "time exceeded" icmp reply as
*not final* reply).
> Do you find it to be a bug or not?
IMO, one of possibilities of traceroute is to detect network loops (where the
same host can appear several times in the output). I assume that the
"18.104.22.168" case is some kind of such a loop (just early filtered somewhere).
The probe packets have not reached this host as a final host. Probably they
passed through it (or someone have NATed the actual reply by its address), but
there are no any "port unreach", "icmp echoreply" or "tcp resets" from this
host, that means that the actual destination of "22.214.171.124" is not reached.
for comment #7 :
I don't think that some special option could be useful here.
Users should see the loops. It follows the "spirit" of tracerouting. Atleast,
"traditional", "cmdline", "network admin" tracerouting...
If users have already seen a loop, they can interrupt the program earlier
(Ctrl-C). (Users already do so when they see a lot of "*" and don't want to wait
when max number of probes will be reached).
According to comments #5 and #8 I decided to close this as NOTABUG, but thanks
to Dan for his effort to create the patch for this problem.