IO::Socket and IPv6
Quanah Gibson-Mount
in IO::Socket I thought I'd let others be aware of. If in your /etc/hosts
file, the IPv6 addresses are listed prior to the IPv4 host address,
IO::Socket will time out. For example, if I have:
127.0.0.1 localhost
::1 localhost
fe00::0 ipv6-localnet
ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
10.11.12.13 myipv4-host.name.domain myipv4-host
IP::Socket will fail when used by Net::LDAP
If I move the 10.11.12.13 address prior to all of the IPv6 pieces, it works
fine. Other IPv4 tools work without issue. So if you see weird behavior
out of Net::LDAP on IPv6 enabled systems even if you are only dealing with
IPv4, this may be the cause.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount
<qua...@zimbra.com> wrote:
> If I move the 10.11.12.13 address prior to all of the IPv6 pieces, it
> works fine. Other IPv4 tools work without issue. So if you see weird
> behavior out of Net::LDAP on IPv6 enabled systems even if you are only
> dealing with IPv4, this may be the cause.
To clarify slightly -- It has to do with the hostname. Specifying a URI of
ldap://<hostname>:389/ fails. Specifying a URI with the IPv4 address
works. So something is broken in how IO::Socket is determining the IPv4
address for the hostname.
Quanah Gibson-Mount
<qua...@zimbra.com> wrote:
> --On Tuesday, March 01, 2011 1:46 PM -0800 Quanah Gibson-Mount
> <qua...@zimbra.com> wrote:
>
>> If I move the 10.11.12.13 address prior to all of the IPv6 pieces, it
>> works fine. Other IPv4 tools work without issue. So if you see weird
>> behavior out of Net::LDAP on IPv6 enabled systems even if you are only
>> dealing with IPv4, this may be the cause.
>
> To clarify slightly -- It has to do with the hostname. Specifying a URI
> of ldap://<hostname>:389/ fails. Specifying a URI with the IPv4 address
> works. So something is broken in how IO::Socket is determining the IPv4
> address for the hostname.
After a bit of debugging, the root problem is Perl's implementation of
inet_aton. I've filed a bug with Perl core.
Quanah Gibson-Mount
wrote:
>> After a bit of debugging, the root problem is Perl's implementation of
>> inet_aton. I've filed a bug with Perl core.
>
> I think it is partly some fault of Net::LDAP
>
> Net::LDAP will use IO::Socket::INET or IO::Socket::INET6 to connect
> depending on if the inet6 option is passed to connect
>
> ::INET will only connect to v4 addresses but I believe ::INET6 will
> connect to either. But there is no guarantee ::INET6 exists
>
> Hm, I wonder if we should just select the default connecting class by
>
> my $connect_class = eval { require IO::Socket::INET6 } ?
> "IO::Socket::INET6" : "IO::Socket::INET";
Hi Graham,
That may indeed fix Net::LDAP's behavior, but any other Perl module out
there that ends up calling IO::Socket::INET which then goes and calls
inet_aton has the possibility of hitting this issue. So I do think it
would be great if it gets fixed at the Perl core level as well. ;)
Quanah Gibson-Mount
wrote:
>
> On Mar 3, 2011, at 12:03 , Quanah Gibson-Mount wrote:
>
>> --On Wednesday, March 02, 2011 9:56 PM -0600 Graham Barr
>> <gb...@pobox.com> wrote:
>>
>>>> After a bit of debugging, the root problem is Perl's implementation of
>>>> inet_aton. I've filed a bug with Perl core.
>>>
>>> I think it is partly some fault of Net::LDAP
>>>
>>> Net::LDAP will use IO::Socket::INET or IO::Socket::INET6 to connect
>>> depending on if the inet6 option is passed to connect
>>>
>>> ::INET will only connect to v4 addresses but I believe ::INET6 will
>>> connect to either. But there is no guarantee ::INET6 exists
>>>
>>> Hm, I wonder if we should just select the default connecting class by
>>>
>>> my $connect_class = eval { require IO::Socket::INET6 } ?
>>> "IO::Socket::INET6" : "IO::Socket::INET";
>>
>> Hi Graham,
>>
>> That may indeed fix Net::LDAP's behavior, but any other Perl module out
>> there that ends up calling IO::Socket::INET which then goes and calls
>> inet_aton has the possibility of hitting this issue. So I do think it
>> would be great if it gets fixed at the Perl core level as well. ;)
>
> But ::INET itself, IIRC, makes assumptions that it is connecting to a v4
> address. so I do not think just changing inet_aton will solve the problem
Hi Graham,
I guess I haven't explained well enough.
Net::LDAP passes IO::Socket::INET a hostname. A hostname that is
configured for both IPv4 and IPv6. The LDAP server is happily bound to
both IPv4 and IPV6.
If /etc/hosts is ordered in one way, the Perl inet_aton function correctly
resolves the IPv4 address. If /etc/hosts is ordered another way, the Perl
inet_aton function fails to resolve the hostname *at all*. This to me is a
bug.
Quanah Gibson-Mount
wrote:
> Hm, I wonder if we should just select the default connecting class by
>
> my $connect_class = eval { require IO::Socket::INET6 } ?
I modified LDAP.pm to only use IO::Socket::INET6, and regardless of IPv4
only or IPv4 + IPv6, it worked with no issue. So this does work well as a
workaround.