Bug 461626

Summary: port incrementation problem during UDP tracing
Product: [Fedora] Fedora Reporter: Milos Malik <mmalik>
Component: tracerouteAssignee: Dmitry Butskoy <dmitry>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: dmitry, jskala
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-11 14:25:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Milos Malik 2008-09-09 15:29:44 UTC
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

Comment 1 Dmitry Butskoy 2008-09-09 17:02:55 UTC
> 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?

Comment 2 Milos Malik 2008-09-10 07:34:43 UTC
I received your e-mail but I hadn't time to respond yet because of too much work. I will respond this week.

Comment 3 Milos Malik 2008-09-10 07:38:00 UTC
I like the second idea -- do not allow the user to specify too high port number.

Comment 4 Dmitry Butskoy 2008-09-11 14:25:46 UTC
Will be fixed in the upcoming 2.0.12

Comment 5 Fedora Update System 2008-09-17 16:19:51 UTC
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

Comment 6 Fedora Update System 2008-09-17 16:22:04 UTC
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

Comment 7 Fedora Update System 2008-10-03 22:28:20 UTC
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.

Comment 8 Fedora Update System 2008-10-03 22:34:26 UTC
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.