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): glibc-2.3.5-10.3.i686 How reproducible: 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 194.199.20.114 and 195.220.108.108, 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. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/ChangeLog.diff?cvsroot=glibc&r1=1.9555&r2=1.9556 http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/posix/Makefile.diff?cvsroot=glibc&r1=1.185&r2=1.186 http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/posix/tst-rfc3484.c.diff?cvsroot=glibc&r1=NONE&r2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/posix/getaddrinfo.c.diff?cvsroot=glibc&r1=1.88&r2=1.89 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.