commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leif John Korshavn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NET-354) FTPSClient not properly supporting CCC and PROT P
Date Thu, 14 Apr 2011 06:07:05 GMT

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

Leif John Korshavn commented on NET-354:
----------------------------------------

OK, I ran CCCTester in explicit mode with commons-net 3.0-SNAPSHOT (commons-net-3.0-20110413.141705-1.jar)
(BTW, I see there is a "ftp"-snapshot aswell, what is in it? commons-net-3.0-20110413.141705-1-ftp.jar
)

Here is the log from my run:

REPLY: 220-FTPD1 IBM FTP CS V1R10 at bmvs0, 05:54:59 on 2011-04-14.
220 Connection will close if idle for more than 5 minutes.
COMMAND: AUTH TLS
REPLY: 234 Security environment established - ready for negotiation
COMMAND: USER <masked out>
REPLY: 331 Send password please.
COMMAND: PASS **********
REPLY: 230 FTZ is logged on.  Working directory is "FTZ.".
COMMAND: PBSZ 0
REPLY: 200 Protection buffer size accepted
COMMAND: PROT P
REPLY: 200 Data connection protection set to private
PBSZ and PROT
COMMAND: CCC
REPLY: 200 CCC command successful
CCC
COMMAND: SYST
REPLY: 215 MVS is the operating system of this server. FTP Server is running on z/OS.
COMMAND: PORT 172,22,14,16,135,146
REPLY: 200 Port request OK.
COMMAND: LIST
REPLY: 125 List started OK
REPLY: 250 List completed successfully.
FILE:   BRODCAST.MSGS

As you can see, it works perfectly also for me.

Since only Erick is able to test in implicit mode, I will take some time today to study the
FTPSClient code for possible incompatibilities with CCC and implicit mode, with special attention
on the SSLSocket-object and its I/O-streams.



> 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: CCCTester.java, 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

Mime
View raw message