On Mar 2, 2011, at 18:37 , Quanah Gibson-Mount wrote:
> --On Tuesday, March 01, 2011 2:01 PM -0800 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.
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";
Graham.
