Skip Menu |

This queue is for tickets about the Net-INET6Glue CPAN distribution.

Report information
The Basics
Id: 78306
Status: rejected
Priority: 0/
Queue: Net-INET6Glue

People
Owner: Nobody in particular
Requestors: MICHIELB [...] cpan.org
Cc: leonerd [...] leonerd.org.uk
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: leonerd [...] leonerd.org.uk
Subject: Not completely compatible with IO::Socket::INET
Hi, I am looking into making the Perl application I work on IPv6 capable. The biggest problem here is IO::Socket::INET is IPv4 only, which makes modules such as LWP, Net::IMAP and such also IPv4 only. I used your excellent module and it seems to make it *just work*. But to be sure, I modified the test suite of IO to use your Glue module, then I ran the tests, and t/io_multihomed.t fails tests 2, 3 and 4. Test Summary Report ------------------- t/io_multihomed.t (Wstat: 0 Tests: 5 Failed: 0) Parse errors: Tests out of sequence. Found (5) but expected (2) Tests out of sequence. Found (6) but expected (3) Tests out of sequence. Found (7) but expected (4) Tests out of sequence. Found (8) but expected (5) Bad plan. You planned 8 tests but ran 5. This means at least unpack_sockaddr_in is not working after using the glue module. Then I changed your module to do the same trick with IO::Socket::INET6 but now with Paul Evan's (cc) IO::Socket::IP and then it passes. So would you consider updating the Glue module to use IO::Socket::IP instead? Then I hope it would work also for modules that use unpack_sockaddr_in. -- Mike
On Wed Jul 11 04:03:19 2012, MICHIELB wrote: Show quoted text
> Then I changed your module to do the same trick with IO::Socket::INET6 > but now with Paul Evan's (cc) IO::Socket::IP and then it passes. So > would you consider updating the Glue module to use IO::Socket::IP > instead? Then I hope it would work also for modules that use > unpack_sockaddr_in.
Any module that tries to use unpack_sockaddr_in() is /inherently/ broken with regards to IPv6 anyway, because unpack_sockaddr_in is specifically for unpacking an AF_INET address, which represents IPv4 only. You should not be manually unpacking addresses in this way, if you want to be IPv6-compatible. See instead the various ->sock* and ->peer* accessor methods on IO::Socket::IP, which work in a family-neutral way. -- Paul Evans
CC: leonerd [...] leonerd.org.uk
Subject: Re: [rt.cpan.org #78306] Not completely compatible with IO::Socket::INET
Date: Wed, 11 Jul 2012 13:29:26 +0200
To: bug-Net-INET6Glue [...] rt.cpan.org
From: Michiel Beijen <michiel.beijen [...] gmail.com>
Hi Paul, thanks for the feedback. On Wed, Jul 11, 2012 at 12:05 PM, Paul Evans via RT <bug-Net-INET6Glue@rt.cpan.org> wrote: Show quoted text
Show quoted text
> Any module that tries to use unpack_sockaddr_in() is /inherently/ broken > with regards to IPv6 anyway, because unpack_sockaddr_in is specifically > for unpacking an AF_INET address, which represents IPv4 only. > > You should not be manually unpacking addresses in this way, if you want > to be IPv6-compatible. See instead the various ->sock* and ->peer* > accessor methods on IO::Socket::IP, which work in a family-neutral way.
Does this mean: 1) the Glue module will only work for modules that do not use unpack_sockaddr_in, some other sock and peer accessors, 2) If we would 'glue' the IO::Socket::IP module instead, these modules WOULD work in IPv4 mode, but they will not get IPv4 capabilities unless the module authors would upgrade the modules to use 'familiy-neutral' accessors, as you describe, in which case the 'glue' module has not much use left, as the module authors would need to update their modules anyway? -- Mike
Show quoted text
> > Does this mean: > 1) the Glue module will only work for modules that do not use > unpack_sockaddr_in, some other sock and peer accessors,
Yes. The Glue stuff is intended for modules which just depend on IO::Socket::INET, instead of IO::Socket::INET6 or IO::Socket::IP and thus cannot use IPv6. Typical examples are Net::SMTP, Net::POP... If these modules also do IPv4 specific stuff like parsing addresses, unpack_sockaddr_in, aton, ntoa.. they cannot be fixed simply by using the Glue module. For instance Net::FTP only handles PORT,PASV commandos which are IPV4 only, so there need to be a special Net::INET6Glue::FTP module to add the missing commands. So the glueing code works in a lot of cases because lots of cases are simple, e.g. module just use IO::Socket::INET but don't do anything IPv4 specific with it. And it's only intended to make 3rd party modules run without changes, if you own the module yourself you should better fix it, so that the glueing is not necessary. Regards, Steffen
CC: leonerd [...] leonerd.org.uk
Subject: Re: [rt.cpan.org #78306] Not completely compatible with IO::Socket::INET
Date: Wed, 11 Jul 2012 14:47:03 +0200
To: bug-Net-INET6Glue [...] rt.cpan.org
From: Michiel Beijen <michiel.beijen [...] gmail.com>
Show quoted text
> The Glue stuff is intended for modules which just depend on > IO::Socket::INET, > instead of IO::Socket::INET6 or IO::Socket::IP and thus cannot use IPv6. > Typical examples are Net::SMTP, Net::POP... > > If these modules also do IPv4 specific stuff like parsing addresses, > unpack_sockaddr_in, aton, ntoa.. they cannot be fixed simply by using > the Glue module. For instance Net::FTP only handles PORT,PASV commandos > which are IPV4 only, so there need to be a special Net::INET6Glue::FTP > module to add the missing commands. > > So the glueing code works in a lot of cases because lots of cases are > simple, e.g. module just use IO::Socket::INET but don't do anything > IPv4 specific with it. > > And it's only intended to make 3rd party modules run without changes, if > you own the module yourself you should better fix it, so that the glueing > is not necessary.
(Un?)fortunately I am not the maintainer of Net::POP3 and such. If your Glue module would glue with Net::Socket::IP using it would at least not break existing modules that use unpack_sockaddr_in - they would not be capable of doing IPv6, but at least using IPv4 they would still be working. Let me describe my use case; I work on OTRS; a ticket system written in Perl. I am investigating what it takes to IPv6-enable the software. We have a module that parses RSS feeds, and a module that loads XML files from a remote HTTP host to install packages on the system. These use LWP; and using your Glue module I was able to make them work with IPv6 hosts. Obviously I do not want to break other (IPv4) stuff but that will happen, if I first 'use' your glue module and then load a module that does some unpack* ipv4. This is the reason I raised this RT ticket. Of course I understand to IPv6 enable all parts of the system, there is still more work to be done, but this would be a start.
On Wed Jul 11 08:47:33 2012, michiel.beijen@gmail.com wrote: Show quoted text
> (Un?)fortunately I am not the maintainer of Net::POP3 and such. > If your Glue module would glue with Net::Socket::IP using it would at > least not break existing modules that use unpack_sockaddr_in - they > would not be capable of doing IPv6, but at least using IPv4 they would > still be working.
I'm not the maintainer either but fortunately it's open-source so obtaining it and writing a patch is trivially simple. Find attached a patch that just swaps Net::POP3 and friends to using IO::Socket::IP instead of ::INET. It passes the libnet distribution's unit tests, but that isn't saying very much because Net::POP3 in particular is never unit-tested and most of the other tests are skipped. :( But, try it out anyway and see how you get on, perhaps it solves your problem? -- Paul Evans
Subject: libnet_using_IO-Socket-IP.patch
=== modified file 'Makefile.PL' --- Makefile.PL 2012-07-11 14:39:36 +0000 +++ Makefile.PL 2012-07-11 15:00:17 +0000 @@ -95,7 +95,8 @@ 'realclean' => {FILES => $config_pm}, PREREQ_PM => { Socket => 1.3, - IO::Socket => 1.05 + IO::Socket => 1.05, + IO::Socket::IP => 0, }, dist => { DIST_DEFAULT => 'mydist', }, @ppd, === modified file 'Net/NNTP.pm' --- Net/NNTP.pm 2012-07-11 14:39:36 +0000 +++ Net/NNTP.pm 2012-07-11 15:00:17 +0000 @@ -8,14 +8,14 @@ use strict; use vars qw(@ISA $VERSION $debug); -use IO::Socket; +use IO::Socket::IP; use Net::Cmd; use Carp; use Time::Local; use Net::Config; $VERSION = "2.24"; -@ISA = qw(Net::Cmd IO::Socket::INET); +@ISA = qw(Net::Cmd IO::Socket::IP); sub new { @@ -731,7 +731,7 @@ Possible options are: B<Host> - NNTP host to connect to. It may be a single scalar, as defined for -the C<PeerAddr> option in L<IO::Socket::INET>, or a reference to +the C<PeerAddr> option in L<IO::Socket::IP>, or a reference to an array with hosts to try in turn. The L</host> method will return the value which was used to connect to the host. === modified file 'Net/POP3.pm' --- Net/POP3.pm 2012-07-11 14:39:36 +0000 +++ Net/POP3.pm 2012-07-11 15:00:17 +0000 @@ -7,7 +7,7 @@ package Net::POP3; use strict; -use IO::Socket; +use IO::Socket::IP; use vars qw(@ISA $VERSION $debug); use Net::Cmd; use Carp; @@ -15,7 +15,7 @@ $VERSION = "2.29"; -@ISA = qw(Net::Cmd IO::Socket::INET); +@ISA = qw(Net::Cmd IO::Socket::IP); sub new { @@ -578,7 +578,7 @@ Possible options are: B<Host> - POP3 host to connect to. It may be a single scalar, as defined for -the C<PeerAddr> option in L<IO::Socket::INET>, or a reference to +the C<PeerAddr> option in L<IO::Socket::IP>, or a reference to an array with hosts to try in turn. The L</host> method will return the value which was used to connect to the host. === modified file 'Net/SMTP.pm' --- Net/SMTP.pm 2012-07-11 14:39:36 +0000 +++ Net/SMTP.pm 2012-07-11 15:00:17 +0000 @@ -12,13 +12,13 @@ use vars qw($VERSION @ISA); use Socket 1.3; use Carp; -use IO::Socket; +use IO::Socket::IP; use Net::Cmd; use Net::Config; $VERSION = "2.31"; -@ISA = qw(Net::Cmd IO::Socket::INET); +@ISA = qw(Net::Cmd IO::Socket::IP); sub new { @@ -554,7 +554,7 @@ A new Net::SMTP object must be created with the I<new> method. Once this has been done, all SMTP commands are accessed through this object. -The Net::SMTP class is a subclass of Net::Cmd and IO::Socket::INET. +The Net::SMTP class is a subclass of Net::Cmd and IO::Socket::IP. =head1 EXAMPLES @@ -609,7 +609,7 @@ will be used. B<Host> - SMTP host to connect to. It may be a single scalar, as defined for -the C<PeerAddr> option in L<IO::Socket::INET>, or a reference to +the C<PeerAddr> option in L<IO::Socket::IP>, or a reference to an array with hosts to try in turn. The L</host> method will return the value which was used to connect to the host. @@ -679,7 +679,7 @@ =item host () -Returns the value used by the constructor, and passed to IO::Socket::INET, +Returns the value used by the constructor, and passed to IO::Socket::IP, to connect to the host. =item etrn ( DOMAIN ) === modified file 'Net/Time.pm' --- Net/Time.pm 2012-07-11 14:39:36 +0000 +++ Net/Time.pm 2012-07-11 15:00:17 +0000 @@ -9,7 +9,7 @@ use strict; use vars qw($VERSION @ISA @EXPORT_OK $TIMEOUT); use Carp; -use IO::Socket; +use IO::Socket::IP; require Exporter; use Net::Config; use IO::Select; @@ -34,7 +34,7 @@ my $me; foreach $host (@$hosts) { - $me = IO::Socket::INET->new( + $me = IO::Socket::IP->new( PeerAddr => $host, PeerPort => $port, Proto => $proto
Show quoted text
> I used your excellent module and it seems to make it *just work*. But to > be sure, I modified the test suite of IO to use your Glue module, then I > ran the tests, and t/io_multihomed.t fails tests 2, 3 and 4. > > Test Summary Report > ------------------- > t/io_multihomed.t (Wstat: 0 Tests: 5 Failed: 0) > Parse errors: Tests out of sequence. Found (5) but expected (2) > Tests out of sequence. Found (6) but expected (3) > Tests out of sequence. Found (7) but expected (4) > Tests out of sequence. Found (8) but expected (5) > Bad plan. You planned 8 tests but ran 5. > > This means at least unpack_sockaddr_in is not working after using the > glue module.
Like I said, you cannot expect to work INET6Glue to work in all cases, but have a look at this special case: - the test defines a module Multi, which is defined as subclass of IO::Socket::INET - it redefines the non-public sub _get_addr. Thus it goes deeply in the implementation interna of IO::Socket::INET. This is ok for the test, because it is a test for IO::Socket::INET, but you will hopefully not see any module which also uses these undocumented interna of IO::Socket::INET. - and because _get_addr does not get called if you replace IO::Socket::INET with IO::Socket::INET6 or IO::Socket::IP (it fails for me with both, because both have no _get_addr method) the subtest 2 will not run. And _get_addr cannot give the faked reply which it verifies in connect, so that subtests 3 and 4 will not run either (connect will be called all the time with a packed 127.0.0.1, and unpack_sockaddr_in works fine) So in this case it has nothing to do with unpack_sockaddr_in. And you cannot expect the glue code to work on code, which access the undocumented internals of IO::Socket::INET Show quoted text
> Then I changed your module to do the same trick with IO::Socket::INET6 > but now with Paul Evan's (cc) IO::Socket::IP and then it passes. So > would you consider updating the Glue module to use IO::Socket::IP > instead? Then I hope it would work also for modules that use > unpack_sockaddr_in.
Like I said, it does not pass with IO::Socket::IP for me. Regards, Steffen
CC: leonerd [...] leonerd.org.uk
Subject: Re: [rt.cpan.org #78306] Not completely compatible with IO::Socket::INET
Date: Wed, 11 Jul 2012 21:58:32 +0200
To: bug-Net-INET6Glue [...] rt.cpan.org
From: Michiel Beijen <michiel.beijen [...] gmail.com>
On Wed, Jul 11, 2012 at 5:05 PM, Paul Evans via RT <bug-Net-INET6Glue@rt.cpan.org> wrote: Show quoted text
> I'm not the maintainer either but fortunately it's open-source so obtaining it and writing a > patch is trivially simple. > > Find attached a patch that just swaps Net::POP3 and friends to using IO::Socket::IP instead of > ::INET. It passes the libnet distribution's unit tests, but that isn't saying very much because > Net::POP3 in particular is never unit-tested and most of the other tests are skipped. :( > > But, try it out anyway and see how you get on, perhaps it solves your problem?
This would solve my problems; yes. I could add your patches to the modules, bundle them in our product, specify IO::Socket::IP as a dependency and it would Just Work. I was thinking about other people wanting to IPv6 upgrade their code. I *understand* it is not nice but would you think it would help to just put the patched versions on CPAN under Net::POP3::IPv6Capable or so, so people can take their existing code, s/Net::POP3/Net::POP3::IPv6Capable/ and would be up and running? Of course, you made a drop-in replacement for IO::Socket::INET but many people are not directly using this module, they are using modules which are in turn using IO::Socket::Inet and thus can not properly use IPv6. -- Mike
Subject: Re: [rt.cpan.org #78306] Not completely compatible with IO::Socket::INET
Date: Wed, 11 Jul 2012 21:59:48 +0200
To: bug-Net-INET6Glue [...] rt.cpan.org
From: Michiel Beijen <michiel.beijen [...] gmail.com>
On Wed, Jul 11, 2012 at 9:43 PM, Steffen Ullrich via RT <bug-Net-INET6Glue@rt.cpan.org> wrote: Show quoted text
> Like I said, it does not pass with IO::Socket::IP for me.
OK, thanks for your help, it was not a good idea. :D -- Mike