Bug 585561 - wrong default ordering of getaddrinfo() IPv4/IPv6 results
Summary: wrong default ordering of getaddrinfo() IPv4/IPv6 results
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: 13
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-24 18:34 UTC by Tomáš Trnka
Modified: 2010-05-06 12:15 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-06 11:30:21 UTC
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 18:36 UTC, Tomáš Trnka
no flags Details

Description Tomáš Trnka 2010-04-24 18:34:34 UTC
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 18:36:22 UTC
Created attachment 408867 [details]
A simple test program

Comment 2 Andreas Schwab 2010-05-04 13:39:42 UTC
What are your interfaces and routes?

Comment 3 Tomáš Trnka 2010-05-04 16:26:09 UTC
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 11:30:21 UTC
This is deliberate, see bug 577626 for details.

Comment 5 Tomáš Trnka 2010-05-06 12:15:59 UTC
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.