This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/644] New: incorrect address ordering by getaddrinfo in rule 9
- From: "stroumf37 at yahoo dot ca" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 7 Jan 2005 17:38:16 -0000
- Subject: [Bug libc/644] New: incorrect address ordering by getaddrinfo in rule 9
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
When calling getaddrinfo on a host on my network, I get these addresses returned
in this order:
192.168.109.29
192.168.93.3
192.168.44.61
192.168.96.2
192.168.2.243
192.168.8.16
192.168.94.2
The host I'm calling getaddrinfo on has this address:
192.168.95.25
getaddrinfo should return 192.168.94.2 first, but doesn't.
I think the problem is in Rule 9 of the code where ffs is used. Here is the
code from the IPv4 part of the rule:
bit1 = ffs (in1_dst->sin_addr.s_addr ^ in1_src->sin_addr.s_addr);
bit2 = ffs (in2_dst->sin_addr.s_addr ^ in2_src->sin_addr.s_addr);
and then
if (bit1 > bit2)
return -1;
if (bit1 < bit2)
return 1;
According to RFC 3484, the longest matching preffix gets higher precedence.
Therefore, we actually do not want the first significat bit (right-most bit)
returned after the XOR of the addresses which is what ffs does, but the
left-most bit. The code for IPv6 does basically the same thing.
--
Summary: incorrect address ordering by getaddrinfo in rule 9
Product: glibc
Version: 2.3.3
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: stroumf37 at yahoo dot ca
CC: glibc-bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=644
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.