IOException when using SSL data connection

Aug 16, 2011 at 8:29 PM
Edited Aug 16, 2011 at 8:41 PM


I've finally come around to testing your nice FTP library. There have been quite a lot changes since I've first downloaded it about a week ago. And yes, it's much faster now! :-)

Anyway, one bug is still there: When I use SSL connection, no data connection works. I won't get a directory listing and I think I also wouldn't get a file's contents. The problem does not arise when I disable DataChannelEncryption. Logging in and all that works but as soon as a data connection is in the game, an IOException "cannot read, socket has been closed" is thrown. Here's the stack trace:


System.IO.IOException: Von der �bertragungsverbindung k�nnen keine Daten gelesen werden:
Eine vorhandene Verbindung wurde vom Remotehost geschlossen. ---> System.Net.Sockets.SocketException:
Eine vorhandene Verbindung wurde vom Remotehost geschlossen bei System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) bei System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) --- Ende der internen Ausnahmestapel�berwachung --- bei System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) bei System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) bei System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) bei System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) bei System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) bei System.Net.Security.SslStream.Read(Byte[] buffer, Int32 offset, Int32 count) bei System.IO.StreamReader.ReadBuffer() bei System.IO.StreamReader.ReadLine() bei System.Net.FtpClient.FtpControlConnection.ReadLine() in ...\NetFtp\FtpControlConnection.cs:Zeile 198. bei System.Net.FtpClient.FtpControlConnection.ReadResponse() in ...\NetFtp\FtpControlConnection.cs:Zeile 547. bei System.Net.FtpClient.FtpDataStream.Close() in ...\NetFtp\FtpDataStream.cs:Zeile 425. bei System.Net.FtpClient.FtpDataStream.Dispose() in ...\NetFtp\FtpDataStream.cs:Zeile 445. bei System.Net.FtpClient.FtpClient.GetRawListing(String path, FtpListType type) in ...\NetFtp\FtpClient.cs:Zeile 267. bei System.Net.FtpClient.FtpClient.GetListing(String path, FtpListType type) in ...\NetFtp\FtpClient.cs:Zeile 303.
Aug 16, 2011 at 8:38 PM


What server software and version are you connecting to? Also are you using active or passive mode transfers? Something that would also help is the transaction log. You can set FtpControlConnection.FtpLogStream to a file stream to save the transaction to a file or you can use Console.OpenStandardOutput() to log it to a console. When you get me this info I'll dig in. I haven't seen any problems at all with ssl on data channels so I need some more info to try and re-produce it.



Aug 16, 2011 at 8:46 PM

Inserted some line breaks above. Stupid forum software.

The FTP server I am connecting to is ProFTPd 1.3.2c on Ubuntu 10.04 server x64. I am using passive mode I guess, at least that's what I'm reading from the session transcript.

I can't seem to enable logging as you suggested because I cannot find a link to FtpControlConnection. I am using the FtpClient class to open a connection, get listings and files. I cannot remember to have found some starter example so this is what I came up with. Not sure whether it's the intended use of the library.

conn = new FtpClient(userName, password, hostName, 21);
conn.SslMode = FtpSslMode.Explicit;
//conn.DataChannelEncryption = false;   // TODO: Workaround for SSL bug
conn.GetListing("/");   // IOException

Aug 16, 2011 at 8:51 PM

Ah, just copying the output from Visual Studio:

> 220 ProFTPD 1.3.2c Server ( FTP server) [::ffff:]
> 234 AUTH TLS successful
< PBSZ 0
> 200 PBSZ 0 successful
> 200 Protection set to Private
< USER ******
> 331 Password required for ******
< PASS [omitted for security]
> 230-You've logged on 2142 times, ******. Last login was on 2011-08-16 21:46:02
> 230 User ****** logged in
> 211-Features:
>  UTF8
>  MFF modify;;UNIX.mode;
>  MLST modify*;perm*;size*;type*;unique*;*;UNIX.mode*;UNIX.owner*;
>  LANG de-DE.UTF-8*
> 211 End
> 200 Type set to A
> 229 Entering Extended Passive Mode (|||17420|)
< MLSD /
> 150 Opening ASCII mode data connection for MLSD
Eine Ausnahme (erste Chance) des Typs "System.IO.IOException" ist in System.dll aufgetreten.
Eine Ausnahme (erste Chance) des Typs "System.IO.IOException" ist in System.dll aufgetreten.

Aug 16, 2011 at 8:51 PM

Sorry, FtpControlConnection.FtpLogStream is a static property. You can set it like so:

static void Main(string[] args) {
  FtpControlConnection.FtpLogStream = new FileStream("foobar.txt");
  // and continue you running your program as normal
In the meantime I'll see about getting a server setup with proftpd. I've seen a bug previously in these forums with ssl and pureftpd on the same version of ubuntu if I recall correctly. I wrote it off because the same bug didn't exist on debian with pureftpd. I'll get an ubuntu test system setup and see what I can come up with.

Aug 16, 2011 at 9:35 PM

Do you have access to the proftpd.conf file? If so what is the option value for TLSRenegotiate? From the proftpd TLS howto:

Question: My FTPS client sometimes times out after uploading/downloading more than 1 GB of data. When I turn off SSL/TLS, the upload/download works. Why?
Answer: The culprit behind this is most likely SSL/TLS renegotiations. By default, mod_tls uses SSL/TLS renegotiations to periodically update the session key which protects the data being transferred; see the
TLSRenegotiate documentation for more details, particularly the time-based and bytes-based limits at which renegotations are forced.

Some FTPS clients, however, do not support server-initiated SSL/TLS renegotations. When the server does try to force a renegotiation, the client fails that new handshake, cannot upload/download any more data over the protected channel, and the transfer will eventually time out. Alternatively, the transfer could terminate strangely in the middle of the upload/download. Note, however, that not all transfer issues will be caused by SSL/TLS renegotiations. Bugs in firewalls and routers can also cause these symptoms.

Should you suspect that you are having issues with your FTPS client because of SSL/TLS renegotiations, you can configure mod_tls to accept renegotiations if the client requests one, but not to otherwise force them:

  TLSRenegotiate required off
Aug 16, 2011 at 9:39 PM

It wasn't set and setting it doesn't change anything to the reported exception. (I have removed the setting again.)

The error occurs right when requesting the very first directory listing, not only after some time.

If you like, I can setup an FTP account for you to test with.

Aug 16, 2011 at 9:41 PM

Alright, that would great. I won't be able to setup an ubuntu server until some time later.

Aug 16, 2011 at 9:47 PM

You have mail.

Aug 16, 2011 at 9:48 PM

Got it, thanks. Will get back as soon as I know something.

Aug 16, 2011 at 10:22 PM

OK, I don't know what the problem is other than it has to do with your SSL certificate or SSL settings in proftpd. It could also be a bug in libssl on ubuntu 10.04 because as I mentioned earlier, I had a SSL bug report a while back that was equally as strange and on ubuntu 10.04. I've tested with file zilla's explicit SSL and the same thing happens, your server immediately drops the connection. In the System.Net.FtpClient code I've tried a number of ways to change how and what is used to authenticate the certificate your server sends for the data connection and nothing works. The code fails on the authentication, as soon as it's attempted your server drops the connection. Like I said, it's not just happening to my code, it's also happening with the filezilla ftp client.

Aug 16, 2011 at 10:35 PM

Alright. Beyond Compare (my FTP client) also does this. So I'm continuing my search on the server side. I'm using FTP so rarely that I didn't even notice it wasn't working...

Thank you for your effort in investigating this anyway!

Aug 16, 2011 at 11:46 PM
Edited Aug 16, 2011 at 11:48 PM

I suspect this option could have something to do with it, however when I set it on a dev server at work it caused a different problem entirely however the fact that it immediately drops the connection when the authentication is taking place still points this way:

Also note the TLSOptions it mentions in the description. The problem is that it's only happening on the data connection which is strange, you would think it would fail on the control connections SSL negotiation as well.