[enhancement] change default port
Bug #416150 reported by
centx
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
iputils (Fedora) |
Fix Released
|
Medium
|
|||
iputils (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Not really a bug, but I found tracepath's output to be pretty inaccurate, with lots of "no reply"-replies.
This led me to the bug-report on https:/
I'd suggest to incorporate the patches from this report if possible, though I made one _very_ unobtrusive that just changes the default port, which worked for me.
Please either update this package for karmic (if that fixes this) or add this patch.
description: | updated |
Changed in iputils (Fedora): | |
status: | Unknown → Fix Released |
Changed in iputils (Fedora): | |
importance: | Unknown → Medium |
To post a comment you must log in.
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 az.sprintbbd. net (24.221.129.1) asymm 2 93.968ms
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.
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 az.sprintbbd. net (24.221.129.1) asymm 2 93.968ms
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.
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 az.sprintbbd. net (24.221.129.1) asymm 2 223.267ms reached
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.
Resume: pmtu 1500 hops 3 back 2
[vaj4088@coyote ~]$