Bug #61432 for Net-FTPSSL: Override PASV IP address, and override HELP lookup

Fri Sep 17 12:26:57 2010 arthurdent99 [...] hotmail.com - Ticket created

Subject:

Override PASV IP address, and override HELP lookup

I am submitting a patch to Net::FTPSSL to correct two issues by adding three new options: Commands, SiteCommands, and OverridePASV. A particular vendor that I have to deal with runs an FTPS server that identifies itself as "Connect:Enterprise UNIX". Connect:Enterprise is a product of Sterling Commerce (www.sterlingcommerce.com). IBM just acquired Sterling Commerce from AT&T on August 27th. There appears to be an issue with Connect:Enterprise when the HELP command is issued. The first "214" line of HELP is sent encrypted, but the following list of recognized commands is sent in cleartext for some reason, which breaks the command channel. I do not understand why the list of commands is being sent in cleartext; this behavior does not occur with vsftpd. Net::FTPSSL displays the first "214" line, then displays "555 Unexpected EOF on command channel socket!". A Wireshark capture confirms that the entire conversation is encrypted except for the list of commands (which is quite readable). To get around the issue, I have added two new options to the new() constructor: Commands, and SiteCommands. Both the Commands and SiteCommands options expect a reference to an array. By passing a list of recognized commands to new(), the HELP cache in the code is pre-populated, so the HELP command never actually runs. With this option, I am finally able to upload a file to a Connect:Enterprise FTPS server. This could also come in handy for those sites where HELP reports that a certain command is usable, but trying to use that command breaks the connection; if you can override the list of acceptable commands from the start, you can prevent the command from being used. I have been dealing with two separate vendors running Connect:Enterprise. Both FTPS sites have the same HELP command issue. I am sure that others who have to deal with this software would appreciate these new options. Another option I have added to the new() constructor is the OverridePASV option, which is either true or false. This comes in handy when the FTPS server has not been properly configured to report back the correct IP address to the PASV command. The other vendor using Connect:Enterprise is reporting the internal, non-routable IP address of their FTPS server (10.x.x.x) in the PASV command output, instead of their external IP address. This seems to be an issue with vendors who do not know how to properly set up their FTPS server. I called them and explained that there is an option in their server software to change the IP address reported by the PASV command, but they claim that option does not exist in Connect:Enterprise. I do not believe that, but in any case they're not going to fix their server. The data channel can't route to the invalid IP address, so the connection times out. The OverridePASV option will cause Net::FTPSSL to ignore the IP address portion of the PASV command output, and it will continue to use the original address of the connection. This may not work in situations where round-robin DNS is being used by the vendor to load-balance FTPS connections, but vendors who are doing load balancing are usually smart enough to configure their FTPS servers properly in the first place. FileZilla will automatically override the IP address returned by the PASV command if it determines that the IP address is unroutable. That could be another method to use instead of having an OverridePASV option, but I went with a very simple patch as proof-of-concept. It shouldn't be too hard to add automatic detection of unroutable IP addresses if you wanted to do that instead. FileZilla does not try to run the HELP command (it tries to run FEAT instead, which fails), so perhaps that's why FileZilla has been working as well. I also can't make a TLS connection to these two FTPS sites using Net::FTPSSL, although FileZilla can make TLS connections to these sites. That's a separate issue, though, so I'll file that under a separate ticket. I have been able to get around this so far by forcing an SSL connection instead. FYI, I am running Red Hat Enterprise Linux 5.5, with Perl 5.8.8, and Net::FTPSSL 0.15. Thanks, Chris Thompson

Subject:

debugfile.txt

Net-FTPSSL Version: 0.15 Server (port): ftps.amajorbank.com (20021) SKT <<< 220 Welcome to A Major Bank Data Distribution Services. Time = 10:32:37 SKT >>> AUTH SSL SKT <<< 234 AUTH TLS-P/SSL OK. >>> USER myusername <<< 331 Password required for myusername. >>> PASS ******* <<< 230 Connect:Enterprise UNIX login ok, access restrictions apply. >>> TYPE A <<< 200 Type set to A. >>> PBSZ 0 <<< 200 PBSZ 0 OK. >>> PROT P <<< 200 PROT P OK, data channel will be secured. >>> PASV <<< 227 Entering Passive Mode (11,22,33,44,82,8) >>> HELP <<< 214- The following commands are recognized (* =>'s unimplemented). <<+ 555 Unexpected EOF on command channel socket! <<+ 502 Unknown command ALLO. >>> STOR myfile.txt <<+ 555 Can't read command channel socket: >>> QUIT <<+ 555 Can't write command on socket: Broken pipe <<+ 555 Unexpected EOF on command channel socket!

Subject:

FTPSSL.015.patch

--- FTPSSL.pm 2010-04-27 11:02:25.000000000 -0500 +++ FTPSSL.pm.new 2010-09-16 15:39:19.000000000 -0500 @@ -69,6 +69,8 @@ my $arg = (ref ($_[0]) eq "HASH") ? $_[0] : {@_}; my %ssl_args; # Only referenced via $advanced. + my @supported_cmds; # Only referenced via $commands. + my @supported_site_cmds; # Only referenced via $site_commands. my $encrypt_mode = $arg->{Encryption} || EXP_CRYPT; my $port = $arg->{Port} || (($encrypt_mode eq IMP_CRYPT) ? 990 : 21); @@ -88,6 +90,12 @@ my $advanced = (ref ($arg->{SSL_Advanced}) eq "HASH") ? $arg->{SSL_Advanced} : \%ssl_args; + my $commands = (ref ($arg->{Commands}) eq "ARRAY") + ? $arg->{Commands} : \@supported_cmds; + my $site_commands = (ref ($arg->{SiteCommands}) eq "ARRAY") + ? $arg->{SiteCommands} : \@supported_site_cmds; + my $override_pasv = $arg->{OverridePASV} || 0; + # Determine where to write the Debug info to ... if ( $use_logfile ) { my $open_mode = ( $debug == 2 ) ? ">>" : ">"; @@ -207,6 +215,11 @@ ${*$obj}{data_prot} = $data_prot; ${*$obj}{Croak} = $die; ${*$obj}{FixPutTs} = ${*$obj}{FixGetTs} = $pres_ts; + ${*$obj}{Commands} = $commands; + ${*$obj}{SiteCommands} = $site_commands; + ${*$obj}{Host} = $host; + ${*$obj}{OverridePASV} = $override_pasv; + ${*$obj}{ftpssl_filehandle} = $FTPS_ERROR if ( $debug == 2 ); $FTPS_ERROR = undef; @@ -273,7 +286,14 @@ my @address = split( /,/, $3 ); - my $host = join( '.', @address[ 0 .. 3 ] ); + my $host; + if (${*$self}{OverridePASV}) { + $host = ${*$self}{Host}; + _print_LOG ( $self, "--- Overriding PASV mode IP address with: $host\n" ); + } + else { + $host = join( '.', @address[ 0 .. 3 ] ); + } my $port = $address[4] * 256 + $address[5]; my $socket; @@ -1365,6 +1385,46 @@ return ( (defined $hlp) ? $hlp : \%help ); } + my @commands = @{${*$self}{Commands}}; + my @site_commands = @{${*$self}{SiteCommands}}; + my $helpmsg; + + if ($all_cmds && @commands > 0) { + _print_LOG ( $self, "--- Overriding HELP command with the following commands: \n" ); + $helpmsg = "214-The following commands are recognized.\n"; + foreach (@commands) { + $help{$_} = 1 if ($_ !~ m/[*]$/); + $helpmsg .= " $_\n"; + _print_LOG ( $self, "--- Command: " . $_ . "\n" ); + } + $helpmsg .= "214 Help OK.\n"; + } + elsif ($site_cmd && @site_commands > 0) { + _print_LOG ( $self, "--- Overriding SITE HELP command with the following commands: \n" ); + $helpmsg = "214-The following commands are recognized.\n"; + foreach (@site_commands) { + $help{$_} = 1 if ($_ !~ m/[*]$/); + $helpmsg .= " $_\n"; + _print_LOG ( $self, "--- Site Command: " . $_ . "\n" ); + } + $helpmsg .= "214 Help OK.\n"; + } + + # If we don't find anything, it's a problem. So don't cache if so ... + if (scalar (keys %help) > 0) { + if ($all_cmds) { + # Add the assumed OPTS command required if FEAT is supported! + # Even though not all servers support OPTS as is required with FEAT. + $help{OPTS} = 1 if ($help{FEAT}); # RFC 2389 + + ${*$self}{help_cmds_found} = \%help; + ${*$self}{help_cmds_msg} = $helpmsg; + } else { + ${*$self}{"help_${cmd}_found"} = \%help; + ${*$self}{"help_${cmd}_msg"} = $helpmsg; + } + } + else { $self->command ("HELP", @_); # Now lets see if we need to parse the result to get a hash of the @@ -1411,6 +1471,7 @@ } else { ${*$self}{"help_${cmd}_msg"} = $self->last_message (); } + } return (\%help); }

Fri Sep 17 15:31:08 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, Thanks for reporting this problem and providing a patch. Your description of the issues were well thought out. I'll have to think on what you've sent me for a while. I don't want to break anything else to play nice with Connect:Enterprise when it doesn't want to play nice itself. Just a few questions in the mean time about your 3 issues. What version of IO::SOCKET::SSL, IO::Socket::INET, and Net::SSLeay::Handle are you using. These 3 modules are heavily used by my module. On the PASV command issue: I think your proposed solution is probably the only one that makes sense unless I can figure out how FireZilla determined the IP Address the server returned was bad. I can't use ping sine quite a few servers disable responding to ping. Does it look like FireZilla times out before it retries with the same host instead of the returned value? Just checking if the IP Address of the host changes doesn't do any good since a server is allowed to redirect the data channel to another server to handle the request. I need to think a bit more before I determine if the new option should be just a flag or require you to specify what host to use for the data chanel. On the TLS vs SSL issue: As long as SSL is working I'll wait on your other ticket with more details. There is no rule that states a server has to support both protocols. I wouldn't be surprised if FireZilla automatically tries SSL if TLS doesn't work. SSL is the older of the 2 protocols after all. So I'm going to consider this a non-issue as far as this ticket is concerned. Finally On the help command: [ $ftps->_help(); ] If I understood you right, the leading 214- was encrypted, the list of commands was in clear text, and the trailing 214 was encrypted again. And once the clear text was encountered, it broke the FTPS connection for my code and nothing else worked again. On the help site command: [ $ftps->_help ("SITE"); ] I really don't think an override option was needed since my code base really doesn't use it. I just provided it since some systems returned a list of site commands while others just returned a syntax statement. So that someone could do $ftps->supported ("SITE", "UMASK"). But I am curious, if you called _help("SITE") in your code did it encounter the same issues as if you just called _help()? What happens if you ran it against another legal command like $ftps->_help("noop")? Or an invalid command like $ftps->_help("xxxx"); I'm just trying to get a feel for how this server handles help in general to prevent other code from breaking. So it might be better if based on what you tell me about my questions above to just allow the user to override the supported() function with their own code like I do for the callback functions against the data channel. Requiring it to be reset before you log in or as an option to new. (login calls supported if you want to preserve timestamps). Or write a sysread() wrapper for response() to re-establish the connection, but that sounds really messy and I'm not sure at this point if it can be done at all without looking at the code much closer. Or look at other creative solutions like your vsftpd program did. Finally, did you run into any other commands besides "HELP" that sent things over the command channel in clear text? Violations of the FTPS spec for the command channel can get really messy to handle.

Fri Sep 17 15:31:10 2010 The RT System itself - Status changed from 'new' to 'open'

Fri Sep 17 20:33:13 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Thanks for your reply. I am using IO::Socket::SSL v1.33, IO::Socket::INET v1.31, Net::SSLeay::Handle v0.61. They're all the latest versions on CPAN at the moment. I believe that FileZilla determines if the IP address is invalid by simply comparing it to the reserved IP addresses listed in RFC 1918. Here is a quote from RFC 1918: --- The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) --- If the IP address returned by PASV falls into any of these three private address spaces, then FileZilla uses the original host instead of the IP address returned by the PASV command. I think that's as far as FileZilla goes to determine if the IP address is invalid. Pinging shouldn't be necessary. Any address that is not in one of those private address spaces should be treated normally. Your description of the HELP issue is correct: the leading 214- was encrypted, the list of commands was in clear text, and the trailing 214 was encrypted again. And once the clear text was encountered, it broke the FTPS connection for your code and nothing else worked again. That's why I pre-loaded the cache that _help creates, so that the actual HELP command will never run. All I am doing in my script is logging in, issuing a put command, and logging out. Put calls _common_put, _common_put calls alloc, alloc calls supported, supported calls _help, and then _help crashes if the HELP command is actually run. I am not directly calling the supported subroutine, it's being called indirectly through put. I threw in the SiteCommands option to pre-load the cache that _help creates for the SITE commands. I haven't actually used any of the SITE commands. I just now ran the $ftps->supported ("SITE", "UMASK") that you mentioned, and it calls _help to do a "HELP SITE" command. The "HELP SITE" command is causing the connection to crash just as the regular HELP command does; the supported SITE commands are returned in cleartext just as the regular HELP commands are. Apparently HELP followed by anything breaks the connection. I haven't really tried sending any other commands other than what's necessary to log in and send a file, so I don't know if there are any other commands that break as spectacularly as HELP. As far as the TLS connection goes, FileZilla starts with an AUTH TLS command, and it succeeds by getting a "234 AUTH TLS-C/TLS OK." message. It never switches to SSL. When I try to connect with TLS using Net::FTPSSL, I get the following message: TLSv1: SSL connect attempt failed with unknown errorerror:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number. But that's really a separate item to worry about. I'm able to connect via SSL, so I'm not terribly worried about it now (even though TLS is supposed to be more secure). I can make a separate ticket for that in the future. I hope I have explained things well. Thanks for your help. Let me know if there's anything else you'd like me to do. Thanks, Chris Thompson

Mon Sep 20 18:04:34 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, Thanks for your reply. Just so you know, I plan on calling the new options OverrideHELP & OverridePASV. Since my docs clearly say that checking if a particular site command is supported depends on the server, I won't be implementing an OverrideHelpSite command at this time. It will just always return false. But maybe I'll change my mind once I start coding. Just so you know, the only 4 commands checked internally are ALLO, NOOP, MFMT and MDTM. So those are the only commands needed in your override array if they are all supported. I'm assuming you don't call supported() yourself in your code. I'm planning to make OverrideHELP accept an array, or a scalar 1 or 0. For always TRUE or always FALSE if you don't want to list all the commands. OverridePASV will take as it's argument the host name. Just in case it has to be redirected to something else. More than likely if you don't provide a name, I'll make sure it defaults to the host name passed. I'm planning on working on the code next weekend as I make tweaks to your patch. I just wish I had access to a server that behaved this way so that I could try out some alternatives to see if I could resolve this dynamically without the need of new option flags. Curtis

Wed Sep 22 10:07:10 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Hello, Thanks for working on this. I'd be happy to test any patches that you come up with. I'll be gone next week on vacation, but I should be available to test things after that. The FTPS sites running Connect:Enterprise that I am dealing with are financial institutions. I can't get you direct access to them, unfortunately. I know it's frustrating trying to fix a problem that you don't have access to. Thanks for pointing out the changes that you will be making. You've obviously put some thought into the best way to make it work. Let me know if I can help in any way. Thanks, Chris Thompson

Mon Sep 27 15:14:44 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, I completed my initial implementation of the patch over the weekend with the override options. Would you care to try it out? If this works for you, we can see about figuring out a more dynamic solution. It may take a bit of trial & error if you are willing to collaborate with me on the fix. But I'm not all that confident that there is a real fix since I don't remember seeing this behavior described in the FTPS specs. My initial idea is to see if I can keep a copy of the original clear channel socket open and see if when the encrypted channel errors out if the original socket connection will pick up after the error. If so drain the socket and go back to the original encrypted channel again. But I doubt if it's that simple. It never really is. Anything that you can send me on what your FTPS server is doing would be extremely helpful since you can't give me access directly. Or if you can find any technical documentation on your server that describes what it is doing on the HELP command. If need be, we can communicate outside this public chain for the nitty gritty details. I look forward to hearing how this patch works for you. Curtis On Wed Sep 22 10:07:10 2010, christhompson wrote: Show quoted text

> Hello, > > Thanks for working on this. I'd be happy to test any patches that you > come up with. I'll be gone next week on vacation, but I should be > available to test things after that. > > The FTPS sites running Connect:Enterprise that I am dealing with are > financial institutions. I can't get you direct access to them, > unfortunately. I know it's frustrating trying to fix a problem that you > don't have access to. > > Thanks for pointing out the changes that you will be making. You've > obviously put some thought into the best way to make it work. > > Let me know if I can help in any way. > > > Thanks, > > Chris Thompson

Subject:

FTPSSL.pm

Message body is not shown because it is too large.

Tue Oct 12 18:02:37 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, I provided you a beta of my fixes to NET-FTPSSL a couple of weeks ago. How goes your testing? I'm going on vacation next week so I'm hoping to get some feedback soon. Curtis

Mon Nov 01 20:39:06 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, Any luck in evaluating the beta I sent you a while ago? I just want to hear if it's working out for you so I can include it in the next release. Curtis On Tue Oct 12 18:02:37 2010, CLEACH wrote: Show quoted text

> Hi Chris, > > I provided you a beta of my fixes to NET-FTPSSL a couple of weeks

ago. Show quoted text

> How goes your testing? I'm going on vacation next week so I'm

hoping to Show quoted text

> get some feedback soon. > > Curtis

Thu Nov 04 13:25:54 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Hello, Sorry to take so long in replying to you. Things have been a bit crazy around here since I returned from vacation. I had to finish a major project for several customers (which is partly why I needed the vacation!). Yes, your changes appear to be working just fine. I am able to override the PASV mode IP address with OverridePASV, and I am able to pass OverrideHELP an array reference (which is good, because Connect:Enterprise doesn't support the MFMT command), and I am also able to pass OverrideHELP a "1" to say that all the commands are supported. It looks good to me! I'm still forced to use SSL instead of TLS when connecting to the Connect:Enterprise servers, but that's a separate issue as I mentioned before. It's working well otherwise, so I'm happy. Thanks so much for your help!

Thu Nov 04 14:00:46 2010 CLEACH [...] cpan.org - Correspondence added

Thanks for the confirmation, It's going to be a bit longer until the official release comes out. I have another feature I'm considering before I make this beta official. I've been asked about adding EPSV and I'm seeing how dificult it would be to add it to the same release as this one. From the specs I've read so far, it may have been a better solution than OverridePASV. I wouldn't be surprised if those other FTP programs you talked about swapped over to EPSV if they had issues with PASV instead of what we came up with. But I plan on supporting both solutions sooner or later. It's just a question if EPSV will make this release or not. Curtis On Thu Nov 04 13:25:54 2010, christhompson wrote: Show quoted text

> Hello, > > Sorry to take so long in replying to you. Things have been a bit

crazy Show quoted text

> around here since I returned from vacation. I had to finish a major > project for several customers (which is partly why I needed the

vacation!). Show quoted text

> > Yes, your changes appear to be working just fine. I am able to

override Show quoted text

> the PASV mode IP address with OverridePASV, and I am able to pass > OverrideHELP an array reference (which is good, because > Connect:Enterprise doesn't support the MFMT command), and I am also

able Show quoted text

> to pass OverrideHELP a "1" to say that all the commands are

supported. Show quoted text

> It looks good to me! > > I'm still forced to use SSL instead of TLS when connecting to the > Connect:Enterprise servers, but that's a separate issue as I

mentioned Show quoted text

> before. It's working well otherwise, so I'm happy. > > Thanks so much for your help!

Thu Nov 04 15:24:30 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Hello, I've attached the log from FileZilla as it connects to one of the Connect:Enterprise servers and uploads a file, to answer your query about whether EPSV was used when PASV returns an invalid address. It appears that FileZilla simply detects the invalid IP address returned by PASV and uses the original address instead. It always uses PASV, and doesn't use EPSV. Also, as you see in the logs, TLS works fine with FileZilla, but doesn't work with Net::FTPSSL. I have to force SSL mode with Net::FTPSSL to get it to work. I wouldn't be at all surprised if Connect:Enterprise is doing something non-standard SSL-wise, but perhaps FileZilla is working around the issue somehow, just as they auto-detect the invalid IP address issue. That's just a guess, however. FileZilla is open source and is written in C++. You can download the source code and the executable from http://filezilla-project.org/download.php , if that will help you any. In any case, your code is working great now. I just replied to answer your question about EPSV. I hope this information is helpful to you. Thanks, Chris Thompson

Subject:

FileZilla.txt

Status: Resolving address of ftps.testsite.com Status: Connecting to 1.2.3.4:10021... Status: Connection established, waiting for welcome message... Response: 220 <<<Connect:Enterprise UNIX 2.4.02 Secure FTP>>> at dsvssw04z FTP server ready. Time = 13:41:52 Command: AUTH TLS Response: 234 AUTH TLS-C/TLS OK. Status: Initializing TLS... Status: Verifying certificate... Command: USER myusername Status: TLS/SSL connection established. Response: 331 Password required for myusername. Command: PASS ******** Response: 230 Connect:Enterprise UNIX login ok, access restrictions apply. Command: SYST Response: 215 UNKNOWN Type: L8 Command: FEAT Response: 500 'FEAT': command not understood. Command: PBSZ 0 Response: 200 PBSZ 0 OK. Command: PROT P Response: 200 PROT P OK, data channel will be secured. Status: Connected Status: Retrieving directory listing... Command: PWD Response: 257 "/myusername" is current directory. Command: TYPE I Response: 200 Type set to I. Command: PASV Response: 227 Entering Passive Mode (10,3,20,11,39,38) Status: Server sent passive reply with unroutable address. Using server address instead. Command: LIST Response: 150 Opening BINARY mode data connection for . Response: 226 Transfer complete. Status: Directory listing successful Status: Resolving address of ftps.testsite.com Status: Connecting to 1.2.3.4:10021... Status: Connection established, waiting for welcome message... Response: 220 <<<Connect:Enterprise UNIX 2.4.02 Secure FTP>>> at dsvssw04z FTP server ready. Time = 13:42:33 Command: AUTH TLS Response: 234 AUTH TLS-C/TLS OK. Status: Initializing TLS... Status: Verifying certificate... Command: USER myusername Status: TLS/SSL connection established. Response: 331 Password required for myusername. Command: PASS ******** Response: 230 Connect:Enterprise UNIX login ok, access restrictions apply. Command: PBSZ 0 Response: 200 PBSZ 0 OK. Command: PROT P Response: 200 PROT P OK, data channel will be secured. Status: Connected Status: Starting upload of C:\Temp\testfile.txt Command: CWD /myusername Response: 250 CWD command successful. Command: PWD Response: 257 "/myusername" is current directory. Command: TYPE A Response: 200 Type set to A. Command: PASV Response: 227 Entering Passive Mode (10,3,20,11,39,38) Status: Server sent passive reply with unroutable address. Using server address instead. Command: STOR testfile.txt Response: 150 Opening ASCII mode data connection for testfile.txt. Response: 226- Transfer complete - acknowledgment message is pending. Response: 226- Transfer complete - acknowledgment message is pending. Response: 226 Transfer complete (Batch Number = 1595). Status: File transfer successful, transferred 39 bytes in 9 seconds Status: Retrieving directory listing... Command: TYPE I Response: 200 Type set to I. Command: PASV Response: 227 Entering Passive Mode (10,3,20,11,39,40) Status: Server sent passive reply with unroutable address. Using server address instead. Command: LIST Response: 150 Opening BINARY mode data connection for . Response: 226 Transfer complete. Status: Directory listing successful

Thu Nov 04 15:39:23 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Oops, I forgot to mention also: apparently Connect:Enterprise doesn't support EPSV. I've attached the list of commands returned by the HELP command, if that will help you any.

Subject:

commands.txt

AUTH SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE PROT REIN* MODE MSND* REST XCWD HELP PWD MDTM PBSZ QUIT RETR MSOM* RNFR LIST NOOP XPWD CCC USER PORT STOR MSAM* RNTO NLST MKD CDUP PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU

Wed Dec 01 13:09:45 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, Sorry about taking so long in getting the official release to FTPSSL v0.16 out. Getting the other new features into this release took a bit longer than expected. The major difference from the beta I sent you earlier is the addition of EPSV as well. Curtis

Wed Dec 01 13:10:50 2010 CLEACH [...] cpan.org - Fixed in 0.16 added

Wed Dec 01 13:12:17 2010 CLEACH [...] cpan.org - Status changed from 'open' to 'resolved'

Thu Dec 02 12:03:41 2010 arthurdent99 [...] hotmail.com - Correspondence added

From:

arthurdent99 [...] hotmail.com

Hello, I just tried to install your new version from CPAN, and I received the following error during "make test". The server was running Red Hat Enterprise Linux 5.3 with Perl 5.8.8. Do you think that it's just a matter of some of the tests needing to be updated, or are there other issues that I need to worry about? [root@jfs Net-FTPSSL-0.16]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00-basic.t .... ok t/10-complex.t .. 1/57 # # You can also perform a deeper test. # Some information will be required for this test: # A secure ftp server address, a user, a password and a directory # where the user has permissions to read and write. # # Do you want to make a deeper test ? [y/N] t/10-complex.t .. 2/57 # Looks like you planned 57 tests but ran 50. t/10-complex.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 7/57 subtests (less 49 skipped subtests: 1 okay) Test Summary Report ------------------- t/10-complex.t (Wstat: 65280 Tests: 50 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 57 tests but ran 50. Files=2, Tests=53, 5 wallclock secs ( 0.04 usr 0.02 sys + 0.20 cusr 0.14 csys = 0.40 CPU) Result: FAIL Failed 1/2 test programs. 0/53 subtests failed. make: *** [test_dynamic] Error 255

Thu Dec 02 12:03:42 2010 The RT System itself - Status changed from 'resolved' to 'open'

Thu Dec 02 12:27:40 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, A quick question. Are you trying to test against a server with your HELP issue? Or the PASV issue? The test cases don't take these issues into consideration. I'll have to take a look at t/10-complex.t to see if I can address that issue. In the mean time, can you tar up all the t/*.txt files and send them to me? I'd like to verify if that's the case. If it is, I'll have a v0.17 out in a few days that asks if we have to consider that problem. My best guess at this point is that you will answer yes to one of the above questions & I still have croak turned on when the command fails. One of these days I'll have to clean up the test script. It's gotten real messy over time. In the mean time I'll look into the croak issue while I'm waiting for your response. Curtis On Thu Dec 02 12:03:41 2010, christhompson wrote: Show quoted text

> Hello, > > I just tried to install your new version from CPAN, and I received

the Show quoted text

> following error during "make test". The server was running Red Hat > Enterprise Linux 5.3 with Perl 5.8.8. Do you think that it's just a > matter of some of the tests needing to be updated, or are there other > issues that I need to worry about? > > [root@jfs Net-FTPSSL-0.16]# make test > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/00-basic.t .... ok > t/10-complex.t .. 1/57 # > # You can also perform a deeper test. > # Some information will be required for this test: > # A secure ftp server address, a user, a password and a directory > # where the user has permissions to read and write. > # > # Do you want to make a deeper test ? [y/N] > > t/10-complex.t .. 2/57 # Looks like you planned 57 tests but ran 50. > t/10-complex.t .. Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 7/57 subtests > (less 49 skipped subtests: 1 okay) > > Test Summary Report > ------------------- > t/10-complex.t (Wstat: 65280 Tests: 50 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 57 tests but ran 50. > Files=2, Tests=53, 5 wallclock secs ( 0.04 usr 0.02 sys + 0.20

cusr Show quoted text

> 0.14 csys = 0.40 CPU) > Result: FAIL > Failed 1/2 test programs. 0/53 subtests failed. > make: *** [test_dynamic] Error 255

Tue Dec 14 18:06:17 2010 CLEACH [...] cpan.org - Correspondence added

Hi Chris, I haven't heard back from you on issues with the test script of v0.16. As I suspected, it was an issue with the 10-complex.t test script instead of the release itself. As I looked into it I discovered serveral issues and started on a redesign of it. It did indeed fail if you didn't ask for a deaper test (fixed), and I added a check to see if the server connection needed to use OverrideHELP to avoid a lot of failures when you requested a deaper test. But I'm at a loss at this point without something to test against to automate the detection of the need to use OverridePASV in the test script as the deaper test is being performed. I need to see some log files to see if I can detect it. I don't really like adding an additional quesion for the deaper test, since that would only confuse anyone doing the testing. There is going to be a v0.17 hopefully before X-Mass if I can ever finish off the changes to 10-complex.t. Curtis On Thu Dec 02 12:27:40 2010, CLEACH wrote: Show quoted text

> Hi Chris, > > A quick question. Are you trying to test against a server with your > HELP issue? Or the PASV issue? The test cases don't take these > issues into consideration. > > I'll have to take a look at t/10-complex.t to see if I can address > that issue. > > In the mean time, can you tar up all the t/*.txt files and send them > to me? I'd like to verify if that's the case. If it is, I'll have

a Show quoted text

> v0.17 out in a few days that asks if we have to consider that

problem. Show quoted text

> > My best guess at this point is that you will answer yes to one of

the Show quoted text

> above questions & I still have croak turned on when the command > fails. One of these days I'll have to clean up the test script.

It's Show quoted text

> gotten real messy over time. > > In the mean time I'll look into the croak issue while I'm waiting

for Show quoted text

> your response. > > Curtis > > On Thu Dec 02 12:03:41 2010, christhompson wrote:

> > Hello, > > > > I just tried to install your new version from CPAN, and I received

> the

> > following error during "make test". The server was running Red Hat > > Enterprise Linux 5.3 with Perl 5.8.8. Do you think that it's just

a Show quoted text

> > matter of some of the tests needing to be updated, or are there

other Show quoted text

> > issues that I need to worry about? > > > > [root@jfs Net-FTPSSL-0.16]# make test > > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > > t/00-basic.t .... ok > > t/10-complex.t .. 1/57 # > > # You can also perform a deeper test. > > # Some information will be required for this test: > > # A secure ftp server address, a user, a password and a directory > > # where the user has permissions to read and write. > > # > > # Do you want to make a deeper test ? [y/N] > > > > t/10-complex.t .. 2/57 # Looks like you planned 57 tests but ran

50. Show quoted text

> > t/10-complex.t .. Dubious, test returned 255 (wstat 65280, 0xff00) > > Failed 7/57 subtests > > (less 49 skipped subtests: 1 okay) > > > > Test Summary Report > > ------------------- > > t/10-complex.t (Wstat: 65280 Tests: 50 Failed: 0) > > Non-zero exit status: 255 > > Parse errors: Bad plan. You planned 57 tests but ran 50. > > Files=2, Tests=53, 5 wallclock secs ( 0.04 usr 0.02 sys + 0.20

> cusr

> > 0.14 csys = 0.40 CPU) > > Result: FAIL > > Failed 1/2 test programs. 0/53 subtests failed. > > make: *** [test_dynamic] Error 255

> >

Subject:

10-complex.t

Message body is not shown because it is too large.

Tue Jan 04 12:29:04 2011 CLEACH [...] cpan.org - Correspondence added

Hi Chris, The problem was just in t/10-complex.t when you answered "No" to the deaper test. There wasn't a bug in the Net::FTPSSL class itself with regards to this ticket. The new release that just came out (v0.17) fixed that test issue and now tests for both your issues so the deeper tests should work for your problem servers as well. But of course I can't 100% guarentee it since I don't have any servers with your issues. I'd appreciate you running the new t/10-complex.t against your servers. No need to update what you are running today to do this test. There was also another minor bug fix in this release that may or may not have affected you. But if you ever see your commands & responses begining to not match, I'd recommend you upgrade then. Since the bug was in retrieving the response to the command. Curtis On Tue Dec 14 18:06:17 2010, CLEACH wrote: Show quoted text

> Hi Chris, > > I haven't heard back from you on issues with the test script of > v0.16. As I suspected, it was an issue with the 10-complex.t test > script instead of the release itself. > > As I looked into it I discovered serveral issues and started on a > redesign of it. It did indeed fail if you didn't ask for a deaper > test (fixed), and I added a check to see if the server connection > needed to use OverrideHELP to avoid a lot of failures when you > requested a deaper test. > > But I'm at a loss at this point without something to test against to > automate the detection of the need to use OverridePASV in the test > script as the deaper test is being performed. I need to see some

log Show quoted text

> files to see if I can detect it. I don't really like adding an > additional quesion for the deaper test, since that would only

confuse Show quoted text

> anyone doing the testing. > > There is going to be a v0.17 hopefully before X-Mass if I can ever > finish off the changes to 10-complex.t. > > Curtis > > > On Thu Dec 02 12:27:40 2010, CLEACH wrote:

> > Hi Chris, > > > > A quick question. Are you trying to test against a server with

your Show quoted text

> > HELP issue? Or the PASV issue? The test cases don't take these > > issues into consideration. > > > > I'll have to take a look at t/10-complex.t to see if I can address > > that issue. > > > > In the mean time, can you tar up all the t/*.txt files and send

them Show quoted text

> > to me? I'd like to verify if that's the case. If it is, I'll

have Show quoted text

> a

> > v0.17 out in a few days that asks if we have to consider that

> problem.

> > > > My best guess at this point is that you will answer yes to one of

> the

> > above questions & I still have croak turned on when the command > > fails. One of these days I'll have to clean up the test script.

> It's

> > gotten real messy over time. > > > > In the mean time I'll look into the croak issue while I'm waiting

> for

> > your response. > > > > Curtis > > > > On Thu Dec 02 12:03:41 2010, christhompson wrote:

> > > Hello, > > > > > > I just tried to install your new version from CPAN, and I

received Show quoted text

> > the

> > > following error during "make test". The server was running Red

Hat Show quoted text

> > > Enterprise Linux 5.3 with Perl 5.8.8. Do you think that it's

just Show quoted text

> a

> > > matter of some of the tests needing to be updated, or are there

> other

> > > issues that I need to worry about? > > > > > > [root@jfs Net-FTPSSL-0.16]# make test > > > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > > > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > > > t/00-basic.t .... ok > > > t/10-complex.t .. 1/57 # > > > # You can also perform a deeper test. > > > # Some information will be required for this test: > > > # A secure ftp server address, a user, a password and a directory > > > # where the user has permissions to read and write. > > > # > > > # Do you want to make a deeper test ? [y/N] > > > > > > t/10-complex.t .. 2/57 # Looks like you planned 57 tests but ran

> 50.

> > > t/10-complex.t .. Dubious, test returned 255 (wstat 65280,

0xff00) Show quoted text

> > > Failed 7/57 subtests > > > (less 49 skipped subtests: 1 okay) > > > > > > Test Summary Report > > > ------------------- > > > t/10-complex.t (Wstat: 65280 Tests: 50 Failed: 0) > > > Non-zero exit status: 255 > > > Parse errors: Bad plan. You planned 57 tests but ran 50. > > > Files=2, Tests=53, 5 wallclock secs ( 0.04 usr 0.02 sys +

0.20 Show quoted text

> > cusr

> > > 0.14 csys = 0.40 CPU) > > > Result: FAIL > > > Failed 1/2 test programs. 0/53 subtests failed. > > > make: *** [test_dynamic] Error 255

> > > >

> >

Tue Jan 04 12:30:48 2011 CLEACH [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Jan 04 12:31:19 2011 CLEACH [...] cpan.org - Ticket deleted

Tue Jan 04 12:31:24 2011 CLEACH [...] cpan.org - Status changed from 'deleted' to 'open'

Tue Jan 04 12:33:47 2011 CLEACH [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Jan 04 12:33:48 2011 CLEACH [...] cpan.org - Fixed in 0.17 added