Description of problem: During UDP tracing the port numbers are incremented by each probe. But as soon as the port number reaches the value 65535, the utility stops incrementing the port numbers and uses just 0 as port number. Version-Release number of selected component (if applicable): traceroute-2.0.10-1.fc8 How reproducible: Always Steps to Reproduce: $ strace -o output.txt traceroute -p 65530 -n -m 6 redhat.com $ cat output.txt | grep connect Actual results: Port number is increased by each probe. If the number reaches 65535 then all following port numbers are equal to 0 (are not incremented). Expected results: Port number is increased by each probe. If the number reaches 65535 then the next port number will be equal to 0 and the incrementation will continue. Additional info: $ strace -o output.txt traceroute -p 65530 -n -m 6 redhat.com traceroute to redhat.com (209.132.177.50), 6 hops max, 40 byte packets 1 10.34.35.254 0.478 ms 0.313 ms 0.295 ms 2 10.34.255.253 0.932 ms 0.621 ms 1.008 ms 3 62.40.67.133 9.263 ms 8.711 ms 8.841 ms 4 146.188.2.145 8.510 ms 9.084 ms 8.505 ms 5 146.188.2.137 18.694 ms 19.132 ms 18.553 ms 6 146.188.15.125 107.069 ms 107.218 ms 106.674 ms $ cat output.txt | grep connect connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.34.32.125")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.34.32.125")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.34.32.125")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.34.32.125")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.34.32.125")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(65530), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(4, {sa_family=AF_INET, sin_port=htons(65531), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(65532), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(6, {sa_family=AF_INET, sin_port=htons(65533), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(7, {sa_family=AF_INET, sin_port=htons(65534), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(8, {sa_family=AF_INET, sin_port=htons(65535), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(9, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(10, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(11, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(12, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(13, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(14, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(15, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(16, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(17, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(18, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0 connect(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("209.132.177.50")}, 28) = 0
> Expected results: > Port number is increased by each probe. > If the number reaches 65535 then the next port number > will be equal to 0 and the incrementation will continue. Yes, and the initial (as in rhel4) traceroute-1.4.a12 behaves exactly so. But the port number of "0" is not a good idea anyway. As well as the continuing from the port number 1 etc. -- it breaks the whole idea to choose some "unused" ports. Two ways: - exit with failure when the port number overflows - do not allow the user to specify too bug port numbers (i.e. max is 65535 - 255 (max hops) * 10 (max probes) == 62985 ) What do you think? Milos, Did you receive my private e-mail?
I received your e-mail but I hadn't time to respond yet because of too much work. I will respond this week.
I like the second idea -- do not allow the user to specify too high port number.
Will be fixed in the upcoming 2.0.12
traceroute-2.0.12-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/traceroute-2.0.12-1.fc9
traceroute-2.0.12-1.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/traceroute-2.0.12-1.fc8
traceroute-2.0.12-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
traceroute-2.0.12-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.