--On Thursday, March 03, 2011 12:35 PM -0600 Graham Barr <gb...@pobox.com>
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
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
