Bug 461626 - port incrementation problem during UDP tracing
port incrementation problem during UDP tracing
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: traceroute (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Dmitry Butskoy
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-09 11:29 EDT by Milos Malik
Modified: 2008-10-03 18:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-11 10:25:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milos Malik 2008-09-09 11:29:44 EDT
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 13:02:55 EDT
> 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 03:34:43 EDT
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 03:38:00 EDT
I like the second idea -- do not allow the user to specify too high port number.
Comment 4 Dmitry Butskoy 2008-09-11 10:25:46 EDT
Will be fixed in the upcoming 2.0.12
Comment 5 Fedora Update System 2008-09-17 12:19:51 EDT
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 12:22:04 EDT
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 18:28:20 EDT
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 18:34:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.