From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1 Description of problem: In some cases, tracepath continues tracing although it has already reached the intended destination host. For example: [vaj4088@coyote ~]$ tracepath 24.221.130.104 1: 192.168.0.241 (192.168.0.241) 0.314ms pmtu 1500 1: firewall (192.168.0.250) 0.578ms 2: 10.253.1.1 (10.253.1.1) asymm 3 84.814ms 3: aztutmrt01.az.sprintbbd.net (24.221.129.1) asymm 2 93.968ms 4: <deleted> (24.221.130.104) asymm 5 162.687ms 5: no reply 6: no reply 7: no reply 8: no reply 9: no reply 10: no reply 11: no reply 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply 20: no reply 21: no reply 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply 31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 [vaj4088@coyote ~]$ tracepath should have stopped at the line labeled "4:", but continued on. <deleted> is a name from my /etc/hosts file that has been deleted to protect the name of an innocent bystander. Version-Release number of selected component (if applicable): iputils-20020927-22 How reproducible: Always Steps to Reproduce: My example shows how I reproduce the problem. Networks being what they are, I don't know how to reproduce it in your circumstances. Actual Results: See description. Expected Results: Should have looked something like: [vaj4088@coyote ~]$ tracepath 24.221.130.104 1: 192.168.0.241 (192.168.0.241) 0.314ms pmtu 1500 1: firewall (192.168.0.250) 0.578ms 2: 10.253.1.1 (10.253.1.1) asymm 3 84.814ms 3: aztutmrt01.az.sprintbbd.net (24.221.129.1) asymm 2 93.968ms 4: <deleted> (24.221.130.104) asymm 5 162.687ms Resume: pmtu 1500 hops 4 back 3 [vaj4088@coyote ~]$ Additional info: Note that the following works fine: [vaj4088@coyote ~]$ tracepath 24.221.129.1 1: 192.168.0.241 (192.168.0.241) 0.342ms pmtu 1500 1: firewall (192.168.0.250) 0.581ms 2: 10.253.1.1 (10.253.1.1) asymm 3 121.557ms 3: aztutmrt01.az.sprintbbd.net (24.221.129.1) asymm 2 223.267ms reached Resume: pmtu 1500 hops 3 back 2 [vaj4088@coyote ~]$
Created attachment 131624 [details] This patch changes the default destination port number to 33434 (which was assigned by IANA for tracerouting) and fixes the bug in a simple but functional way :]
(In reply to comment #1) > This patch changes the default destination port number to 33434 (which was > assigned by IANA for tracerouting) and fixes the bug in a simple but functional > way :] > Dan - Thanks for the effort, but I can set the port number on the command line and I still get the same result if I choose 33434 as the port number. This is using Fedora Core 5, which takes the command as tracepath 24.221.130.104/33434 I think that the root cause needs to be understood and corrected. Thanks!
(In reply to comment #2) > (In reply to comment #1) > > This patch changes the default destination port number to 33434 (which was > > assigned by IANA for tracerouting) and fixes the bug in a simple but functional > > way :] > > > > Dan - > Thanks for the effort, but I can set the port number on the command line and I > still get the same result if I choose 33434 as the port number. > This is using Fedora Core 5, which takes the command as > tracepath 24.221.130.104/33434 > > I think that the root cause needs to be understood and corrected. > Thanks! Yes, I know that the port number is not a solution to your problem. It's only another bug that the patch fixes. The patch makes more changes in the code of tracepath. Please apply the patch first and then test it again. It works for me: mildew> patch -p1 < ../iputils-20020927-trace_stop.patch patching file tracepath.c ... mildew> ./tracepath 24.221.130.104 ... ... 20: sl-bb22-stk-15-0.sprintlink.net (144.232.4.242) asymm 16 218.962ms 21: sl-bb22-stk-15-0.sprintlink.net (144.232.4.242) asymm 16 217.624ms 22: sl-bb23-sj-10-0.sprintlink.net (144.232.20.113) asymm 15 216.131ms 23: sl-bbwl-4-0-0.sprintlink.net (144.228.111.42) asymm 16 252.138ms 24: cpe-24-221-130-104.az.sprintbbd.net (24.221.130.104) asymm 19 274.079ms reached Resume: pmtu 1500 hops 24 back 19 I think the root cause is not in tracepaht but in the reply from 24.221.130.104 (it sends "host unreachable" instead of "connection refused") btw. traceroute has the same problem with this machine.
Patch applied on rawhide, thanks a lot
Created attachment 134099 [details] New option -c, default UDP port change
The addition of an option to control stopping makes sense to me (but why 'c'?). I do not have a development environment for testing the patch, so I am unable to confirm or deny its correctness. Thanks for your efforts!
I applied this patch, tested it, and it works nice. Thank you Dan.
(In reply to comment #6) > The addition of an option to control stopping makes sense to me (but why 'c'?). > I do not have a development environment for testing the patch, so I am unable to > confirm or deny its correctness. > Thanks for your efforts! c -> compare :]