I¹ve tried this with a proprietary Java client that is known to work with other FTP servers like wu_ftp and ws_ftp, and I¹ve also tried it with the FileZilla client.
Here are the steps to reproduce the problem with FileZilla: 1. Connect using the ³FTP over TLS (explicit encryption)² server type in FileZilla (and passive mode). 2. Accept the server cert. The control connection is successfully established and protected. 3. Double-click to drill into an empty directory on the server. FileZilla reports the following: >> Error: Can't establish SSL connection >> Error: Could not retrieve directory listing >> Response: 226 Closing data connection. As reported by Dave Roberts, the problem only occurs when the directory on the server is empty. (I incorrectly stated in my original post that it happens with *any* command that uses the data connection.) I know this sounds a lot like FTPSERVER-42, which has been fixed: http://issues.apache.org/jira/browse/FTPSERVER-42 But I think this problem is slightly different, because I have the FTPSERVER-42 fix, and I'm no longer seeing a problem listing empty directories in the non-SSL case (at least with the clients I've tried). Clint On 1/17/07 11:09 PM, "Niklas Gustavsson" <[EMAIL PROTECTED]> wrote: > Clinton Foster wrote: >> How are things coming with the SSL support and MINA? I'm having some issues >> securing the data connection in passive mode with the old code. The SSL >> handshaking works fine on the control connection, and the server seems to >> respond as expected when the client sends the PROT P command to request that >> the data connection also be secured. However, when the server tries to send >> anything to the client on the data connection, as soon as the server closes >> the data connection the client gets an SSL handshaking error. My theory is >> that the handshake is not happening immediately when the client makes the >> data connection to the server, so when the server sends the data the client >> mistakes it for the initiation of the handshake. >> >> Possibly this is a case of user error, but before I get too deep into >> debugging it, I thought I should ask how things are going with MINA and SSL. > > I checked in the final changes to getting SSL support working with MINA > yesterday. However, this only covers the control channel. So far I've > not started any work on migrating the data channel code to MINA (however > it's on my todo list). So, any problems you see with PROT will likely > still happen even if using the MINA listener. > > We do have some tests for the scenario you describe above. They seem to > work so we'll need to dig some further. What client are you using? Could > you described they steps you perform to reproduce the problem with that > client? > > /niklas >
