Stefan Bauer schrieb:
> Am 27.02.2010 17:43, Fabian Knittel schrieb:
>> With a few tweaks to /etc/gai.conf I managed to change the order:
>>
>> $ python -c "import socket; print socket.getaddrinfo(None, 'auth',
>> 0, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)"
>> [(10, 1, 6, '', ('::', 113, 0, 0)), (2, 1, 6, '', ('0.0.0.0', 113))]
>> ^^ ^^^^^^^
>> IPv6 IPv4
>
> That's how it is displayed in my case. gai.conf is empty. Right now
> i dont see, where this behavior comes from.
Great, so we've now established the reason for the differences in your
and our tests!
Although we haven't determined _why_ getaddrinfo behaves differently, it
obviously does. oidentd should be able to cope with the difference the
same way it should be able to cope with different values for
/proc/sys/net/ipv6/bindv6only.
The current works / fails matrix as far as I see it:
| bindv6only = 0 | bindv6only = 1
--------------------------+-------------------------+----------------
getaddrinfo -> ipv6 first | works (*) | works
getaddrinfo -> ipv4 first | fails to listen on IPv6 | works (**)
(*) Although oidentd fails to open the second socket, the failure has no
visible effect as the first socket listens for IPv4 and IPv6 traffic
simultaneously.
(**) This appears to be the default on current squeeze systems with a
2.6.32 Linux kernel.
So my patch only makes a difference for one specific system
configuration (ipv4 first and bindv6only = 0).
> I hope you understand
> that i'm very cautious about patching upstream source as long as we
> dont have eliminated all the doughts, where this problem really relies.
I understand that very well. Too bad we don't have upstream to ease the
process. :)
>> With the tweak in effect, oidentd worked without my patch - using only a
>> single IPv6 socket which accepted both IPv4 and IPv6. (This would break
>> for /proc/sys/net/ipv6/bindv6only=1.)
>
> I can not confirm this either.
Please disregard that side-comment, it was a mistake, sorry. If my
statement were correct, it would have meant that my proposed patch would
break in the "getaddrinfo -> ipv6 first" case.
The above matrix should correctly reflect the cases where it fails /
succeeds.
> I just enabled bindv6only and tried
> to connect again to oidentd on ipv4 and ipv6:
>
> Mar 1 09:04:34 black oidentd[18481]: Connection from
> cl-849.dus-01.de.sixxs.net (2a01:198:200:350::2):39062
> Mar 1 09:04:42 black oidentd[18490]: Connection from
> p5B0822FB.dip0.t-ipconnect.de (91.8.34.251):1548
>
> black:/home/sb# lsof -itcp:113
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> oidentd 18443 oident 6u IPv6 48082507 TCP *:auth (LISTEN)
> oidentd 18443 oident 7u IPv4 48082508 TCP *:auth (LISTEN)
>
> Now it binds two 2 single sockets but that's really no advantage or
> disadvantage at all.
Correct. In the bindv6only=1 case _or_ with my patch, there will always
be two single sockets. In the bindv6only=0 case and without my patch,
there will always only be a single socket. The second socket will
conflict with the first and (silently) fail to open.
I've attached my /etc/gai.conf with all assumed defaults enabled. I
don't know whether that suffices to achieve "getaddrinfo -> ipv4 first"
on your system, but it might be worth a try and works on my system.
Cheers
Fabian
# Configuration for getaddrinfo(3).
#
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting. But the RFC also says that system
# administrators should be able to overwrite the defaults. This can be
# achieved here.
#
# All lines have an initial identifier specifying the option followed by
# up to two values. Information specified in this file replaces the
# default information. Complete absence of data of one kind causes the
# appropriate default information to be used. The supported commands include:
#
# reload <yes|no>
# If set to yes, each getaddrinfo(3) call will check whether this file
# changed and if necessary reload. This option should not really be
# used. There are possible runtime problems. The default is no.
#
# label <mask> <value>
# Add another rule to the RFC 3484 label table. See section 2.1 in
# RFC 3484. The default is:
#
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
label 2001:0::/32 7
#
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
#
# precedence <mask> <value>
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96 100
#
# scopev4 <mask> <value>
# Add another rule to the RFC 3484 scope table for IPv4 addresses.
# By default the scope IDs described in section 3.2 in RFC 3484 are
# used. Changing these defaults should hardly ever be necessary.
# The defaults are equivalent to:
#
scopev4 ::ffff:169.254.0.0/112 2
scopev4 ::ffff:127.0.0.0/104 2
scopev4 ::ffff:10.0.0.0/104 5
scopev4 ::ffff:172.16.0.0/108 5
scopev4 ::ffff:192.168.0.0/112 5
scopev4 ::ffff:0.0.0.0/96 14
