Red Hat Bugzilla – Bug 174927
pb in sysdeps/posix/getaddrinfo.c, rfc3484_sort()
Last modified: 2007-11-30 17:11:18 EST
Description of problem:
The implementation of Rule 9 of the rfc3284 algorithms, should not use ffs() to
obtain the bit-length of the common prefix between a source and destination IP
address, because dotted IPv4 address A.B.C.D is represented as integer
D<<24+C<<16+B<<8+A on i386, and looking for a common prefix, starting for the
LSB (bit 0) of this integer, refers to bit7 of the network address.
Version-Release number of selected component (if applicable):
with wget-1.10.2 (that uses getaddrinfo). [wget-1.9.x uses gethostbyname()]
My IP address at home is 82.xx.xx.xx, and when I launch "wget http://rpmfind.net
", it always uses the same IP address, altought rpmfind.net is a round-robin dns
resolving to 126.96.36.199 and 188.8.131.52, in no specific order.
When Rule 9 of rfc 3484 searches for the common prefix between 82.xx.xx.xx and
both resolved addresses, it compares bit1=ffs ( 82 ^ 194 ) and bit2=ffs ( 82 ^
195 ) first, around line 1410.
source: 82 = 01010010
dest1: 194 = 11000010
dest2: 195 = 11000011
bit1= 5 (starting comparison from LSB)
bit2= 1 (idem)
The real common network prefix is the same for source ^ dest1 and source ^
dest2, we should have bit1=bit2, so no reordering, and getaddrinfo() shouldn't
change the order returned by the DNS request, but it does in this case.
Guess you are talking about BZ#644.
That has been fixed upstream and whenever FC4 update will merge from upstream,
this will be merged in automatically. No need to file bugreports about it.