[ 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