Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 12 Apr 2011 21:48:05 +0000 (UTC)
From: "Erick Lichtas (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1578516469.53495.1302644885794.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1223883320.5074.1297259637696.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
 and PROT P
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019068#comment-13019068 ] 

Erick Lichtas commented on NET-354:
-----------------------------------

I also noticed that the CCC implementation was not correct.  I have applied this patch locally and it does not appear that the autoClose flag set when creating the SSLSocket works as expected when the SSLSocket.close() is called.

If _socket_.close() is called during the handling of the CCC command, the subsequent command (for example SYST) fails with java.net.SocketException: Software caused connection abort: socket write error.  The error specifically happens during the getReply() when reading a line from the controlInput which comes back null.  I've tested this on Windows using java 1.5 and 1.6 and got the same results.  I'm not sure if it behaves any different on linux.

Caused by: java.net.SocketException: Software caused connection abort: socket write error
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
	at java.io.BufferedWriter.flush(BufferedWriter.java:236)
	at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:490)
	at org.apache.commons.net.ftp.FTPSClient.sendCommand(FTPSClient.java:486)
	at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:550)
	at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:599)
	at org.apache.commons.net.ftp.FTP.pasv(FTP.java:948)
	at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:607)
	at org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:521)
	at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2724)
	at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2698)

If I leave the autoClose option true and simply discard the SSLSocket:

// _socket_.close();
_socket_ = _plainSocket 
...

all subsequent commands are executed without problems. 

> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
>                 Key: NET-354
>                 URL: https://issues.apache.org/jira/browse/NET-354
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>         Environment: Applies to all environments
>            Reporter: Leif John Korshavn
>             Fix For: 3.0
>
>         Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
>    _socket.close();
>    _socket = _plainsocket;
>    ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira