Bug #53719 for Net-FTPSSL: Not a bug but a workaround to a server bug.

Fri Jan 15 10:20:54 2010 webb [...] cargotel.com - Ticket created

Subject:	Not a bug but a workaround to a server bug.
Date:	Fri, 15 Jan 2010 09:20:11 -0600
To:	bug-NET-FTPSSL [...] rt.cpan.org
From:	Ben Webb <webb [...] cargotel.com>

Curtis, I would have just emailed you directly but you have your email squashed on CPAN. A server I'm having to communicate with breaks if you send it an ALLO command, so I added an option to disable the allo. My diff follows. I don't know if this is something you want to include or not, but for at least one person it was necessary. Thanks for providing a good module. -- Ben Webb CargoTel ph: 866-227-4683 x719 YIM: benrwebb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -74,6 +74,7 @@ my $data_prot = ($encrypt_mode eq CLR_CRYPT) ? DATA_PROT_CLEAR : ($arg->{DataProtLevel} || DATA_PROT_PRIVATE); my $use_ssl = $arg->{useSSL} || 0; + my $squash_allo = $arg->{squashALLO} || 0; my $die = $arg->{Croak} || $arg->{Die}; my $pres_ts = $arg->{PreserveTimestamp} || 0; my $use_logfile = $debug && (defined $arg->{DebugLogFile} && @@ -189,15 +190,16 @@ } # These options control the behaviour of the Net::FTPSSL class ... - ${*$obj}{Crypt} = $encrypt_mode; - ${*$obj}{debug} = $debug; - ${*$obj}{trace} = $trace; - ${*$obj}{timeout} = $timeout; - ${*$obj}{buf_size} = $buf_size; - ${*$obj}{type} = MODE_ASCII; - ${*$obj}{data_prot} = $data_prot; - ${*$obj}{Croak} = $die; - ${*$obj}{FixPutTs} = ${*$obj}{FixGetTs} = $pres_ts; + ${*$obj}{Crypt} = $encrypt_mode; + ${*$obj}{debug} = $debug; + ${*$obj}{trace} = $trace; + ${*$obj}{timeout} = $timeout; + ${*$obj}{buf_size} = $buf_size; + ${*$obj}{type} = MODE_ASCII; + ${*$obj}{data_prot} = $data_prot; + ${*$obj}{squash_allo} = $squash_allo; + ${*$obj}{Croak} = $die; + ${*$obj}{FixPutTs} = ${*$obj}{FixGetTs} = $pres_ts; ${*$obj}{ftpssl_filehandle} = $FTPS_ERROR if ( $debug == 2 ); $FTPS_ERROR = undef; @@ -814,8 +816,8 @@ return undef; # Already decided not to call croak if you get here! } - # If alloc_size is already set, I skip this part - unless ( defined ${*$self}{alloc_size} ) { + # If alloc_size is already set or we squash allo, I skip this part + unless ( defined ${*$self}{alloc_size} || ${*$self}{squash_allo} ) { if ( $close_file && -f $file_loc ) { my $size = -s $file_loc; $self->alloc($size);

Fri Jan 15 13:51:07 2010 CLEACH [...] cpan.org - Broken in 0.14 added

Fri Jan 15 13:51:08 2010 CLEACH [...] cpan.org - Severity Normal added

Fri Jan 15 14:41:17 2010 CLEACH [...] cpan.org - Correspondence added

Hi Ben, I'm always looking for ways to improve this module. And I prefer contact via the bug report so that I can track problems to their resolution. Emails just tend to get lost if I can't deal with it immediately. To bad you contacted me just after I released v0.14, so now this fix will need to wait on v0.15, which may be a while. In the mean time, since I can't reproduce your problem, I'd appreciate if you could run a test for me and send back the log file so that I can see the actual problem you encountered. Since I have an idea for a more elegant solution. There is a boolean function called supported() in this class. And I'd prefer to make the check dynamic instead of adding a new option that someone needs to examine source code to figure out if they need to use it or not. The servers I have just ignore the ALLO command if it isn't supported, which is why the code didn't test for success. But if your server connection is dying, I need to make a change. So I'd appreciate it if you could run the following code for me without using your new squash_allo option and return the allo_test.txt file for analysis to me as well as what was printed to your screen. Please replace all "..." with appropriate values for your server. $ftp=Net::FTP->new(....,Debug=>1,DebugLogFile=>"allo_test.txt",Croak=>1); $ftp->login (..., ...); $h = $ftp->supported ("allo"); print "*** ALLO Supported? ", ($h ? "TRUE" : "FALSE"), "\n"; $ftp->put (...); # So I can see it fail. $ftp->quit (); Don't worry about the overhead of supported(), it just runs the "HELP" command the first time it's called. Afterward each call to supported() references an internal hash of all the commands the server said it supports. So only your 1st call to put() would result in an additional server hit and each subsequent call would skip the server hit. Once I get your results, I'll decide on the best solution to take for future development of this module. Thanks for your help. Curtis On Fri Jan 15 10:20:54 2010, webb@cargotel.com wrote: Show quoted text

> Curtis, > > I would have just emailed you directly but you have your email squashed on > CPAN. A server I'm having to communicate with breaks if you send it

an ALLO Show quoted text

> command, so I added an option to disable the allo. My diff follows. I > don't know if this is something you want to include or not, but for at

least Show quoted text

> one person it was necessary. > > Thanks for providing a good module. > >

Fri Jan 15 14:41:18 2010 The RT System itself - Status changed from 'new' to 'open'

Fri Jan 15 15:22:45 2010 webb [...] cargotel.com - Correspondence added

Subject:	Re: [rt.cpan.org #53719] Not a bug but a workaround to a server bug.
Date:	Fri, 15 Jan 2010 14:22:11 -0600
To:	bug-Net-FTPSSL [...] rt.cpan.org
From:	Ben Webb <webb [...] cargotel.com>

Curtis, Thanks for the quick response. I'm attaching all relevant files. One thing to note - I have to pass some less than normal commands within the session to set up an upload. That is because this is not an ftp server but a mainframe connection tool that more or less supports the ftp protocol. Also, I manually broke and truncated the screen grab. It was looping and I was going to run out of buffer. On Fri, Jan 15, 2010 at 1:41 PM, Curtis Leach via RT < bug-Net-FTPSSL@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > Hi Ben, > > I'm always looking for ways to improve this module. And I prefer > contact via the bug report so that I can track problems to their > resolution. Emails just tend to get lost if I can't deal with it > immediately. > > To bad you contacted me just after I released v0.14, so now this fix > will need to wait on v0.15, which may be a while. > > In the mean time, since I can't reproduce your problem, I'd appreciate > if you could run a test for me and send back the log file so that I can > see the actual problem you encountered. Since I have an idea for a more > elegant solution. > > There is a boolean function called supported() in this class. And I'd > prefer to make the check dynamic instead of adding a new option that > someone needs to examine source code to figure out if they need to use > it or not. The servers I have just ignore the ALLO command if it isn't > supported, which is why the code didn't test for success. But if your > server connection is dying, I need to make a change. > > So I'd appreciate it if you could run the following code for me without > using your new squash_allo option and return the allo_test.txt file for > analysis to me as well as what was printed to your screen. Please > replace all "..." with appropriate values for your server. > > $ftp=Net::FTP->new(....,Debug=>1,DebugLogFile=>"allo_test.txt",Croak=>1); > $ftp->login (..., ...); > $h = $ftp->supported ("allo"); > print "*** ALLO Supported? ", ($h ? "TRUE" : "FALSE"), "\n"; > $ftp->put (...); # So I can see it fail. > $ftp->quit (); > > Don't worry about the overhead of supported(), it just runs the "HELP" > command the first time it's called. Afterward each call to supported() > references an internal hash of all the commands the server said it > supports. So only your 1st call to put() would result in an additional > server hit and each subsequent call would skip the server hit. > > Once I get your results, I'll decide on the best solution to take for > future development of this module. > > Thanks for your help. > > Curtis > > On Fri Jan 15 10:20:54 2010, webb@cargotel.com wrote:

> > Curtis, > > > > I would have just emailed you directly but you have your email squashed

> on

> > CPAN. A server I'm having to communicate with breaks if you send it

> an ALLO

> > command, so I added an option to disable the allo. My diff follows. I > > don't know if this is something you want to include or not, but for at

> least

> > one person it was necessary. > > > > Thanks for providing a good module. > > > >

> > > >

-- Ben Webb CargoTel ph: 866-227-4683 x719 YIM: benrwebb

Message body is not shown because sender requested not to inline it.

Fri Jan 15 16:51:59 2010 CLEACH [...] cpan.org - Correspondence added

Thanks Ben for performing the test. It gives me a lot to work with. Looks like my supported() solution will work for you by making the ALLO conditional. It did detect properly that ALLO wasn't supported. So I don't need a new option. It can be done dynamically. But your screen shot and log file suggests I might have a bug in my code when the server unexpectedly closes the connection. I didn't like the stuff that was being written to your screen. Or the fact that my code was in a loop of sending "ABOR" commands to your server. This strongly suggests a runaway error routine on my part. So I'm going to have to figure out why it's looping like that. Would you mind downloading v0.14 and retrying the test? I had improved some error checking in that release. It would be nice to confirm that those fixes didn't help with this particular issue. If you do this test, also add "Trace=>1" as one of the options to new(). It may cause additional info to be written to your screen. Either way I may send you a beta next week if you are willing to help me determine what's causing the loop. Curtis

Fri Jan 15 16:58:33 2010 webb [...] cargotel.com - Correspondence added

Subject:	Re: [rt.cpan.org #53719] Not a bug but a workaround to a server bug.
Date:	Fri, 15 Jan 2010 15:58:16 -0600
To:	bug-Net-FTPSSL [...] rt.cpan.org
From:	Ben Webb <webb [...] cargotel.com>

I will try to over the weekend. I'm in the uncomfortable spot of not owning the server that is creating the problem (otherwise I would have fixed the server not to drop the connection on an allo... where is the error handling here?) The supported() test is a good idea, I was just in a hurry and needed it to work. Thanks again, Ben On Fri, Jan 15, 2010 at 3:52 PM, Curtis Leach via RT < bug-Net-FTPSSL@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > Thanks Ben for performing the test. It gives me a lot to work with. > > Looks like my supported() solution will work for you by making the ALLO > conditional. It did detect properly that ALLO wasn't supported. So I > don't need a new option. It can be done dynamically. > > But your screen shot and log file suggests I might have a bug in my code > when the server unexpectedly closes the connection. I didn't like the > stuff that was being written to your screen. Or the fact that my code > was in a loop of sending "ABOR" commands to your server. This strongly > suggests a runaway error routine on my part. So I'm going to have to > figure out why it's looping like that. > > Would you mind downloading v0.14 and retrying the test? I had improved > some error checking in that release. It would be nice to confirm that > those fixes didn't help with this particular issue. > > If you do this test, also add "Trace=>1" as one of the options to new(). > It may cause additional info to be written to your screen. > > Either way I may send you a beta next week if you are willing to help me > determine what's causing the loop. > > Curtis > >

-- Ben Webb CargoTel ph: 866-227-4683 x719 YIM: benrwebb

Fri Jan 15 18:31:25 2010 CLEACH [...] cpan.org - Correspondence added

Hi Ben, There is no need to download it over the weekend. I found the loop and it's still in the v0.14 code base. So I'll reach out to you again when I have a beta for you to check out. _croak_or_return() calls _abort(), which calls command(), which calls _croak_or_return() again. We are now caught in an infinite recursive loop! I think it only happens when Croak=>1 is turned on. I'm also going to fix quot() so that it's no longer restricted to what's returned by HELP. Since by your example it's obvious that some unsupported FTP commands are not acknowledged to exist by the server. and it was for those extra misc commands like "routing" that this method was created to handle in the 1st place. Curtis On Fri Jan 15 16:58:33 2010, webb@cargotel.com wrote: Show quoted text

> I will try to over the weekend. I'm in the uncomfortable spot of not

owning Show quoted text

> the server that is creating the problem (otherwise I would have fixed the > server not to drop the connection on an allo... where is the error

handling Show quoted text

> here?) > > The supported() test is a good idea, I was just in a hurry and needed

it to Show quoted text

> work. > > Thanks again, > > Ben > > On Fri, Jan 15, 2010 at 3:52 PM, Curtis Leach via RT < > bug-Net-FTPSSL@rt.cpan.org> wrote: >

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > Thanks Ben for performing the test. It gives me a lot to work with. > > > > Looks like my supported() solution will work for you by making the ALLO > > conditional. It did detect properly that ALLO wasn't supported. So I > > don't need a new option. It can be done dynamically. > > > > But your screen shot and log file suggests I might have a bug in my code > > when the server unexpectedly closes the connection. I didn't like the > > stuff that was being written to your screen. Or the fact that my code > > was in a loop of sending "ABOR" commands to your server. This strongly > > suggests a runaway error routine on my part. So I'm going to have to > > figure out why it's looping like that. > > > > Would you mind downloading v0.14 and retrying the test? I had improved > > some error checking in that release. It would be nice to confirm that > > those fixes didn't help with this particular issue. > > > > If you do this test, also add "Trace=>1" as one of the options to new(). > > It may cause additional info to be written to your screen. > > > > Either way I may send you a beta next week if you are willing to help me > > determine what's causing the loop. > > > > Curtis > > > >

> >

Fri Jan 15 18:33:02 2010 CLEACH [...] cpan.org - Broken in 0.12 added

Mon Jan 18 10:19:24 2010 webb [...] cargotel.com - Correspondence added

Subject:	Re: [rt.cpan.org #53719] Not a bug but a workaround to a server bug.
Date:	Mon, 18 Jan 2010 09:18:02 -0600
To:	bug-Net-FTPSSL [...] rt.cpan.org
From:	Ben Webb <webb [...] cargotel.com>

Replies inline... On Fri, Jan 15, 2010 at 5:31 PM, Curtis Leach via RT < bug-Net-FTPSSL@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > Hi Ben, > > There is no need to download it over the weekend. I found the loop and > it's still in the v0.14 code base. So I'll reach out to you again when > I have a beta for you to check out. >

Sounds great, thanks. Show quoted text

> > _croak_or_return() calls _abort(), which calls command(), which calls > _croak_or_return() again. We are now caught in an infinite recursive > loop! I think it only happens when Croak=>1 is turned on. > >

That may be true. When I first encountered the error I had Croak off, Debug set to 2 and trace turned on. I didn't get the screen output I saw when I ran the test for you, just a long timeout and an eventual fail. Show quoted text

> I'm also going to fix quot() so that it's no longer restricted to what's > returned by HELP. Since by your example it's obvious that some > unsupported FTP commands are not acknowledged to exist by the server. > and it was for those extra misc commands like "routing" that this method > was created to handle in the 1st place. > >

Oddly enough I didn't experience a problem sending a non help listed command with quot, but what I found was that quot automatically uc's the command and for whatever reason that breaks the server. it has to be lower case. At the time I was trying to get it up and running without modifying any of the library code so that lead me to just use command rather than change the way quot works. Thanks again for your help, Ben Show quoted text

> Curtis > > On Fri Jan 15 16:58:33 2010, webb@cargotel.com wrote:

> > I will try to over the weekend. I'm in the uncomfortable spot of not

> owning

> > the server that is creating the problem (otherwise I would have fixed the > > server not to drop the connection on an allo... where is the error

> handling

> > here?) > > > > The supported() test is a good idea, I was just in a hurry and needed

> it to

> > work. > > > > Thanks again, > > > > Ben > > > > On Fri, Jan 15, 2010 at 3:52 PM, Curtis Leach via RT < > > bug-Net-FTPSSL@rt.cpan.org> wrote: > >

> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > > > Thanks Ben for performing the test. It gives me a lot to work with. > > > > > > Looks like my supported() solution will work for you by making the ALLO > > > conditional. It did detect properly that ALLO wasn't supported. So I > > > don't need a new option. It can be done dynamically. > > > > > > But your screen shot and log file suggests I might have a bug in my

> code

> > > when the server unexpectedly closes the connection. I didn't like the > > > stuff that was being written to your screen. Or the fact that my code > > > was in a loop of sending "ABOR" commands to your server. This strongly > > > suggests a runaway error routine on my part. So I'm going to have to > > > figure out why it's looping like that. > > > > > > Would you mind downloading v0.14 and retrying the test? I had improved > > > some error checking in that release. It would be nice to confirm that > > > those fixes didn't help with this particular issue. > > > > > > If you do this test, also add "Trace=>1" as one of the options to

> new().

> > > It may cause additional info to be written to your screen. > > > > > > Either way I may send you a beta next week if you are willing to help

> me

> > > determine what's causing the loop. > > > > > > Curtis > > > > > >

> > > >

-- Ben Webb CargoTel ph: 866-227-4683 x719 YIM: benrwebb

Mon Apr 19 22:46:01 2010 CLEACH [...] cpan.org - Correspondence added

Ben, I sent you an email a couple of weeks ago asking if you'd like to beta test my fix for you. Could you please let me know if you will be interested in testing it out or not? I'll be glad to resend to your personal email address again if this is so. If I don't hear from you by the end of the week I'm going to post my fixes as is as v0.15, even though I couldn't reproduce your problems locally. Curtis On Mon Jan 18 10:19:24 2010, webb@cargotel.com wrote: Show quoted text

> Replies inline... > > On Fri, Jan 15, 2010 at 5:31 PM, Curtis Leach via RT < > bug-Net-FTPSSL@rt.cpan.org> wrote: >

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > Hi Ben, > > > > There is no need to download it over the weekend. I found the loop

> and

> > it's still in the v0.14 code base. So I'll reach out to you again

> when

> > I have a beta for you to check out. > >

> > Sounds great, thanks. > >

> > > > _croak_or_return() calls _abort(), which calls command(), which

> calls

> > _croak_or_return() again. We are now caught in an infinite

> recursive

> > loop! I think it only happens when Croak=>1 is turned on. > > > >

> That may be true. When I first encountered the error I had Croak

off, Show quoted text

> Debug > set to 2 and trace turned on. I didn't get the screen output I saw > when I > ran the test for you, just a long timeout and an eventual fail. > >

> > I'm also going to fix quot() so that it's no longer restricted to

> what's

> > returned by HELP. Since by your example it's obvious that some > > unsupported FTP commands are not acknowledged to exist by the

> server.

> > and it was for those extra misc commands like "routing" that this

> method

> > was created to handle in the 1st place. > > > >

> Oddly enough I didn't experience a problem sending a non help listed > command > with quot, but what I found was that quot automatically uc's the > command and > for whatever reason that breaks the server. it has to be lower case. > At > the time I was trying to get it up and running without modifying any > of the > library code so that lead me to just use command rather than change > the way > quot works. > > > Thanks again for your help, > > Ben > > >

> > Curtis > > > > On Fri Jan 15 16:58:33 2010, webb@cargotel.com wrote:

> > > I will try to over the weekend. I'm in the uncomfortable spot of

> not

> > owning

> > > the server that is creating the problem (otherwise I would have

> fixed the

> > > server not to drop the connection on an allo... where is the

error Show quoted text

> > handling

> > > here?) > > > > > > The supported() test is a good idea, I was just in a hurry and

> needed

> > it to

> > > work. > > > > > > Thanks again, > > > > > > Ben > > > > > > On Fri, Jan 15, 2010 at 3:52 PM, Curtis Leach via RT < > > > bug-Net-FTPSSL@rt.cpan.org> wrote: > > >

> > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > > > > > Thanks Ben for performing the test. It gives me a lot to work

> with.

> > > > > > > > Looks like my supported() solution will work for you by making

> the ALLO

> > > > conditional. It did detect properly that ALLO wasn't

supported. Show quoted text

> So I

> > > > don't need a new option. It can be done dynamically. > > > > > > > > But your screen shot and log file suggests I might have a bug

in Show quoted text

> my

> > code

> > > > when the server unexpectedly closes the connection. I didn't

> like the

> > > > stuff that was being written to your screen. Or the fact that

> my code

> > > > was in a loop of sending "ABOR" commands to your server. This

> strongly

> > > > suggests a runaway error routine on my part. So I'm going to

> have to

> > > > figure out why it's looping like that. > > > > > > > > Would you mind downloading v0.14 and retrying the test? I had

> improved

> > > > some error checking in that release. It would be nice to

> confirm that

> > > > those fixes didn't help with this particular issue. > > > > > > > > If you do this test, also add "Trace=>1" as one of the options

> to

> > new().

> > > > It may cause additional info to be written to your screen. > > > > > > > > Either way I may send you a beta next week if you are willing

to Show quoted text

> help

> > me

> > > > determine what's causing the loop. > > > > > > > > Curtis > > > > > > > >

> > > > > >

> > > > > > > >

> >

Mon Apr 19 23:46:58 2010 webb [...] cargotel.com - Correspondence added

Subject:	Re: [rt.cpan.org #53719] Not a bug but a workaround to a server bug.
Date:	Mon, 19 Apr 2010 22:46:41 -0500
To:	bug-Net-FTPSSL [...] rt.cpan.org
From:	Ben Webb <webb [...] cargotel.com>

Curtis, Sorry, I must have missed the email the first time around. I'll try to get it tested for you this week. Thanks for your help. Ben On Mon, Apr 19, 2010 at 9:46 PM, Curtis Leach via RT < bug-Net-FTPSSL@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > Ben, > > I sent you an email a couple of weeks ago asking if you'd like to beta > test my fix for you. Could you please let me know if you will be > interested in testing it out or not? I'll be glad to resend to your > personal email address again if this is so. > > If I don't hear from you by the end of the week I'm going to post my > fixes as is as v0.15, even though I couldn't reproduce your problems > locally. > > Curtis > > On Mon Jan 18 10:19:24 2010, webb@cargotel.com wrote:

> > Replies inline... > > > > On Fri, Jan 15, 2010 at 5:31 PM, Curtis Leach via RT < > > bug-Net-FTPSSL@rt.cpan.org> wrote: > >

> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > > > Hi Ben, > > > > > > There is no need to download it over the weekend. I found the loop

> > and

> > > it's still in the v0.14 code base. So I'll reach out to you again

> > when

> > > I have a beta for you to check out. > > >

> > > > Sounds great, thanks. > > > >

> > > > > > _croak_or_return() calls _abort(), which calls command(), which

> > calls

> > > _croak_or_return() again. We are now caught in an infinite

> > recursive

> > > loop! I think it only happens when Croak=>1 is turned on. > > > > > >

> > That may be true. When I first encountered the error I had Croak

> off,

> > Debug > > set to 2 and trace turned on. I didn't get the screen output I saw > > when I > > ran the test for you, just a long timeout and an eventual fail. > > > >

> > > I'm also going to fix quot() so that it's no longer restricted to

> > what's

> > > returned by HELP. Since by your example it's obvious that some > > > unsupported FTP commands are not acknowledged to exist by the

> > server.

> > > and it was for those extra misc commands like "routing" that this

> > method

> > > was created to handle in the 1st place. > > > > > >

> > Oddly enough I didn't experience a problem sending a non help listed > > command > > with quot, but what I found was that quot automatically uc's the > > command and > > for whatever reason that breaks the server. it has to be lower case. > > At > > the time I was trying to get it up and running without modifying any > > of the > > library code so that lead me to just use command rather than change > > the way > > quot works. > > > > > > Thanks again for your help, > > > > Ben > > > > > >

> > > Curtis > > > > > > On Fri Jan 15 16:58:33 2010, webb@cargotel.com wrote:

> > > > I will try to over the weekend. I'm in the uncomfortable spot of

> > not

> > > owning

> > > > the server that is creating the problem (otherwise I would have

> > fixed the

> > > > server not to drop the connection on an allo... where is the

> error

> > > handling

> > > > here?) > > > > > > > > The supported() test is a good idea, I was just in a hurry and

> > needed

> > > it to

> > > > work. > > > > > > > > Thanks again, > > > > > > > > Ben > > > > > > > > On Fri, Jan 15, 2010 at 3:52 PM, Curtis Leach via RT < > > > > bug-Net-FTPSSL@rt.cpan.org> wrote: > > > >

> > > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=53719 > > > > > > > > > > > Thanks Ben for performing the test. It gives me a lot to work

> > with.

> > > > > > > > > > Looks like my supported() solution will work for you by making

> > the ALLO

> > > > > conditional. It did detect properly that ALLO wasn't

> supported.

> > So I

> > > > > don't need a new option. It can be done dynamically. > > > > > > > > > > But your screen shot and log file suggests I might have a bug

> in

> > my

> > > code

> > > > > when the server unexpectedly closes the connection. I didn't

> > like the

> > > > > stuff that was being written to your screen. Or the fact that

> > my code

> > > > > was in a loop of sending "ABOR" commands to your server. This

> > strongly

> > > > > suggests a runaway error routine on my part. So I'm going to

> > have to

> > > > > figure out why it's looping like that. > > > > > > > > > > Would you mind downloading v0.14 and retrying the test? I had

> > improved

> > > > > some error checking in that release. It would be nice to

> > confirm that

> > > > > those fixes didn't help with this particular issue. > > > > > > > > > > If you do this test, also add "Trace=>1" as one of the options

> > to

> > > new().

> > > > > It may cause additional info to be written to your screen. > > > > > > > > > > Either way I may send you a beta next week if you are willing

> to

> > help

> > > me

> > > > > determine what's causing the loop. > > > > > > > > > > Curtis > > > > > > > > > >

> > > > > > > >

> > > > > > > > > > > >

> > > >

-- Ben Webb CargoTel ph: 866-227-4683 x719 YIM: benrwebb

Tue Apr 27 12:24:47 2010 CLEACH [...] cpan.org - Correspondence added

Ben, Thanks for your evaluation of the previous patch last week. Glad it fixed your problem. But sorry to hear that the error case continues to loop. Attached is a new patch to v0.15 so that you can test if the infinite loop problems on error have now been fixed. Can you please do this test with (Croak => 1, Debug =>1, DebugLogFile => "ftps_log.txt") to hit the error condition. I'd like the log file generated and anything written to your screen returned to me for evaluation. Hopefully this will be the last patch needed to fix this problem. Also don't forget to make that change to "sub alloc" where supported references "HELP" instead of "ALLO". So that we can trap the error I'm attempting to fix. Thanks for your help. Curtis On Mon Apr 19 23:46:58 2010, webb@cargotel.com wrote: Show quoted text

> Curtis, > > Sorry, I must have missed the email the first time around. I'll try

to get Show quoted text

> it tested for you this week. > > Thanks for your help. > > Ben >

Subject:

FTPSSL.pm

Message body is not shown because it is too large.

Tue May 18 18:55:30 2010 CLEACH [...] cpan.org - Status changed from 'open' to 'resolved'

Tue May 18 18:55:31 2010 CLEACH [...] cpan.org - Fixed in 0.15 added