Hi,
Due to (my) last fixes on IO::Socket::INET6 multihomed got broken.
Additionally it could happen, that it preferred inet6 even if the
host usually prefers inet6.
This was not detected because the io_multihomed test was assumes
that it will try to connect to inet6 first w/o checking it.
Because the default on OpenBSD is to prefer IPv4 it was detected
by a friend.
The attached patch (against 2.61) contains the following:
- rewrite of io_multihomed test so that it tests the right thing
regardless if the host prefers inet or inet6
- fix for IO::Socket::INET6:
for( my $r=0;$r<@rres;$r+=5 ) {
- next if $rres[0] != $fam_listen; # must be same family
+ next if $rres[$r] != $fam_listen; # must be same family
^^^^
- change to the algorithm for finding out the combinations of
[family,localaddr,peeraddr] so that the order is driven by @rres,
eg the order given by getaddrinfo(peeraddr,AF_UNSPEC).
The problem with the older approach was, that
getaddrinfo('',AF_UNSPEC,AI_PASSIVE) returns on Linux (at least on
my system) inet before inet6, even if the system prefers inet6
before inet.
patch was tested with per5.8.8 and perl5.10.1 on ubuntu10.04 with
inet6 prefered to inet and also the other way.
Regards,
Steffen

Thanks for the patch! I applied it after reviewing it and correcting
these things:
1. Make sure that one does not use tabs (\t) for indentation but rather
4-ws indentation.
2. print $socket "Message" should be print {$socket} "Message" - see PBP.
Regards,
-- Shlomi Fish

> Thanks for the patch! I applied it after reviewing it and correcting
> these things:
>
> 1. Make sure that one does not use tabs (\t) for indentation but rather
> 4-ws indentation.
>
> 2. print $socket "Message" should be print {$socket} "Message" - see PBP.
>
> Regards,
>
> -- Shlomi Fish

The test t/io_multihomed6.t assumes that localhost resolves so 127.0.0.1
and ::1. Looks like that on these systems this is not the case, e.g.
getaddrinfo gives only 127.0.0.1, not ::1.
Attached patch fixes the test in that it skips the test, if localhost
does not resolv to both 127.0.0.1 and ::1.
Thanks for reporting the problem.
Regards,
Steffen
Show quoted text

>
> The test t/io_multihomed6.t assumes that localhost resolves so 127.0.0.1
> and ::1. Looks like that on these systems this is not the case, e.g.
> getaddrinfo gives only 127.0.0.1, not ::1.
>
> Attached patch fixes the test in that it skips the test, if localhost
> does not resolv to both 127.0.0.1 and ::1.

> >
> > The test t/io_multihomed6.t assumes that localhost resolves so 127.0.0.1
> > and ::1. Looks like that on these systems this is not the case, e.g.
> > getaddrinfo gives only 127.0.0.1, not ::1.
> >
> > Attached patch fixes the test in that it skips the test, if localhost
> > does not resolv to both 127.0.0.1 and ::1.

>
> Thanks; that's fixed Fedora 10 but breaks with earlier perls:
>

I've tried to apply a modify version of the patch, and the test script
in question ( "t/io_multihomed6.t") works fine. Which earlier perls do
you refer to? I'm now building perl-5.8.9 and will try it with that. But
any information would be welcome.
Regards,
-- Shlomi Fish

> > > and ::1. Looks like that on these systems this is not the case, e.g.
> > > getaddrinfo gives only 127.0.0.1, not ::1.
> > >
> > > Attached patch fixes the test in that it skips the test, if localhost
> > > does not resolv to both 127.0.0.1 and ::1.

>
> I've tried to apply a modify version of the patch, and the test script
> in question ( "t/io_multihomed6.t") works fine. Which earlier perls do
> you refer to? I'm now building perl-5.8.9 and will try it with that. But
> any information would be welcome.
>

Hi!
I've now tried it with perl-5.8.9 and t/io_multihomed6.t works fine -
how earlier must I go?
Regards,
-- Shlomi Fish

> > > > and ::1. Looks like that on these systems this is not the case, e.g.
> > > > getaddrinfo gives only 127.0.0.1, not ::1.
> > > >
> > > > Attached patch fixes the test in that it skips the test, if

> >
> > I've tried to apply a modify version of the patch, and the test script
> > in question ( "t/io_multihomed6.t") works fine. Which earlier perls do
> > you refer to? I'm now building perl-5.8.9 and will try it with that. But
> > any information would be welcome.
> >

>
> Hi!
>
> I've now tried it with perl-5.8.9 and t/io_multihomed6.t works fine -
> how earlier must I go?

It breaks with the same symptoms on 5.8.8 and earlier. It's a similar
issue to that in RT#54656, and is resolved by the addition of
parentheses around the first operand of the ternary operator, as in the
attached amended patch.
However, I'm still getting problems at runtime with 5.8.3 and earlier:
t/io_multihomed6......Use of uninitialized value in subroutine entry at
t/io_multihomed6.t line 49.
Bad arg length for Socket6::unpack_sockaddr_in6, length is 0, should be
28 at t/io_multihomed6.t line 49.
dubious
Test returned status 255 (wstat 65280, 0xff00)
Scalar found where operator expected at (eval 152) line 1, near "'int'
$__val"
(Missing operator before $__val?)
I'm seeing this same error with 5.8.0 and 5.8.3.

> > >
> > > I've tried to apply a modify version of the patch, and the test script
> > > in question ( "t/io_multihomed6.t") works fine. Which earlier perls do
> > > you refer to? I'm now building perl-5.8.9 and will try it with

>
> It breaks with the same symptoms on 5.8.8 and earlier. It's a similar
> issue to that in RT#54656, and is resolved by the addition of
> parentheses around the first operand of the ternary operator, as in the
> attached amended patch.

Thanks!
I already had a similar bracketing solution in place in the repository
due to style issues.
Show quoted text

>
> However, I'm still getting problems at runtime with 5.8.3 and earlier:
>
> t/io_multihomed6......Use of uninitialized value in subroutine entry at
> t/io_multihomed6.t line 49.
> Bad arg length for Socket6::unpack_sockaddr_in6, length is 0, should be
> 28 at t/io_multihomed6.t line 49.
> dubious
> Test returned status 255 (wstat 65280, 0xff00)
> Scalar found where operator expected at (eval 152) line 1, near "'int'
> $__val"
> (Missing operator before $__val?)
>
> I'm seeing this same error with 5.8.0 and 5.8.3.

I'll try to test and correct that, though perl-5.8.7 and below are
really ancient and supporting them is not a high priority.
Regards,
-- Shlomi Fish

> >
> > It breaks with the same symptoms on 5.8.8 and earlier. It's a similar
> > issue to that in RT#54656, and is resolved by the addition of
> > parentheses around the first operand of the ternary operator, as in the
> > attached amended patch.

>
> Thanks!
>
> I already had a similar bracketing solution in place in the repository
> due to style issues.
>

>
> I'll try to test and correct that, though perl-5.8.7 and below are
> really ancient and supporting them is not a high priority.
>

After some time of getting perl-5.8.0 to build on a recent Mandriva
Linux Cooker, the test appears to work fine:
[quote]
shlomi[inet6]:$module$ ~/apps/perl/5.8.0-debug/bin/perl -Ilib
t/io_multihomed6.t
1..8
ok 1
ok 2 # inet6
ok 3
ok 4
ok 5 # inet
ok 6
ok 7
ok 8
[/quote]
Where did you run into that problem with perl-5.8.0? Where there any
vendor patches? Can you provide a patch against the svn repository:
http://svn.berlios.de/svnroot/repos/web-cpan/IO-Socket-INET6/trunk/
Regards,
-- Shlomi Fish

I'm doing the builds in chroots, installing old distributions into the
chroot and building RPM packages that way. The problematic builds are
for Red Hat Linux 9, Fedora Core 1 and Red Hat Enterprise Linux 3. The
former two of these are "dead" and the latter will join them in around 6
months but I'll see what I can do to debug the issue. It's possible that
it's a side effect of my build system as well as possibly being a
peculiarity of the perl builds (which were more heavily patched back
then than they are now).
Paul.

There is a simple solution to this, just add the following to /etc/hosts:
# For loopbacking.
127.0.0.1 localhost
::1 localhost
I your host support inet6 it should work, otherwise what is the point of
installing IO::Socket::INET6 ;)

>
> I'm doing the builds in chroots, installing old distributions into the
> chroot and building RPM packages that way. The problematic builds are
> for Red Hat Linux 9, Fedora Core 1 and Red Hat Enterprise Linux 3. The
> former two of these are "dead" and the latter will join them in around 6
> months but I'll see what I can do to debug the issue. It's possible that
> it's a side effect of my build system as well as possibly being a
> peculiarity of the perl builds (which were more heavily patched back
> then than they are now).
>

Well, I'm closing this bug because it appears to be fixed. I'll upload a
new version to CPAN soon. Please open a new bug if you have a more
concrete problem (hopefully with a fix).
Regards,
-- Shlomi Fish
Show quoted text