Bug 585561 - wrong default ordering of getaddrinfo() IPv4/IPv6 results
wrong default ordering of getaddrinfo() IPv4/IPv6 results
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-24 14:34 EDT by Tomáš Trnka
Modified: 2010-05-06 08:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-06 07:30:21 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)
A simple test program (520 bytes, text/plain)
2010-04-24 14:36 EDT, Tomáš Trnka
no flags Details

  None (edit)
Description Tomáš Trnka 2010-04-24 14:34:34 EDT
Description of problem:
I just upgraded from F12 to F13 and that broke the precedence of IPv6 addresses over IPv4 (i.e. currently A records are used no matter if an AAAA record exists). I've tracked the problem down to the default getaddrinfo() result ordering - when /etc/gai.conf is empty/nonexistent, IPv4 addresses are sorted first. However, when I paste the supposed default rules from the gai.conf manpage to /etc/gai.conf, suddenly IPv6 is correctly preferred.
I've even tried setting "options inet6" in resolv.conf, but it didn't change anything.

Version-Release number of selected component (if applicable):
glibc-2.11.90-20.x86_64

How reproducible:
always

Steps to Reproduce:
1.get rid of any /etc/gai.conf rules on a machine with IPv6 connectivity
2.run getent ahosts www.nix.cz (calling getaddrinfo() directly in a test program yields the same results)
  
Actual results:
195.47.235.3    STREAM info.nix.cz
195.47.235.3    DGRAM  
195.47.235.3    RAW    
2a02:38::1001   STREAM 
2a02:38::1001   DGRAM  
2a02:38::1001   RAW    

Expected results:
2a02:38::1001   STREAM info.nix.cz
2a02:38::1001   DGRAM  
2a02:38::1001   RAW    
195.47.235.3    STREAM 
195.47.235.3    DGRAM  
195.47.235.3    RAW    

(Of course, using fedoraproject.org exhibits the same behavior, just the outputs are much longer.)
Comment 1 Tomáš Trnka 2010-04-24 14:36:22 EDT
Created attachment 408867 [details]
A simple test program
Comment 2 Andreas Schwab 2010-05-04 09:39:42 EDT
What are your interfaces and routes?
Comment 3 Tomáš Trnka 2010-05-04 12:26:09 EDT
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:19:66:42:b3:ca brd ff:ff:ff:ff:ff:ff
    inet 192.168.169.5/29 brd 192.168.169.7 scope global eth0
    inet6 fe80::219:66ff:fe42:b3ca/64 scope link 
       valid_lft forever preferred_lft forever
3: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
    link/[65534] 
    inet6 2001:0:53aa:64c:2872:9752:a64f:f89d/32 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ffff:ffff:ffff/64 scope link 
       valid_lft forever preferred_lft forever

192.168.169.0/29 dev eth0  proto kernel  scope link  src 192.168.169.5 
169.254.0.0/16 dev eth0  scope link  metric 1002 
default via 192.168.169.1 dev eth0 

unreachable ::/96 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
2001::/32 dev teredo  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit 4294967295
unreachable 2002:a00::/24 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:7f00::/24 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:ac10::/28 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:e000::/19 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev teredo  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit 4294967295
default dev teredo  metric 1029  mtu 1280 advmss 1220 hoplimit 4294967295
Comment 4 Andreas Schwab 2010-05-06 07:30:21 EDT
This is deliberate, see bug 577626 for details.
Comment 5 Tomáš Trnka 2010-05-06 08:15:59 EDT
In that case the gai.conf(5) man page is terribly misleading (claiming a default that is actually not used), please fix it (stating this is a deliberate violation of RFC3484). Perhaps this change of getaddrinfo() behavior should be mentioned in the release notes for F13, too (so that other users do not wonder why something that worked for years suddenly broke without warning).

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