Archived Forum Post

Index of archived forum posts


Intermittent Failed to convert data connection to TLS Error

Sep 01 '14 at 08:42

I am using the FTP2 component for Chilkat .NET 4.5 to download a number of text files from a remote FTP server that uses client certificates for authentication.

When I test in my development environment it downloads all of the files successfully, but when I deploy my application and run the process it will download five or ten files and then report the following problem when downloading a file: Failed to convert data connection to TLS.

It is odd because it will download several files with no problem then suddenly report this problem. Also, it's odd that I don't get this error in my development environment, but I do get it in the production environment.

Any ideas?

Here are the configuration settings I use before establishing the connection to the FTP server:

The error log follows...

There was an error when attempting to electronically receive EDI files for LAC DMH (IBHIS Claiming):

Message: ChilkatLog:
    DllDate: Jul 31 2014
    UnlockPrefix: ...
    Username: ...
    Architecture: Little Endian; 64-bit
    Language: .NET 4.5 / x64
    VerboseLogging: 1
      enabled: yes
      heartbeatMs: 0
      sendBufferSize: 65536
    AutoGetSizeForProgress: 0
      localFilename: ...
        ModeZ: 0
        BinaryMode: 1
            sendingCommand: PBSZ 0
            replyLineQP: 200 PBSZ Command OK. Protection buffer size set to 0.
            commandResponse: 200 PBSZ Command OK. Protection buffer size set to 0.
            statusCode: 200
            readResponse: Elapsed time: 62 millisec
            sendingCommand: PROT P
            replyLineQP: 200 PROT Command OK. Using Private data connection
            commandResponse: 200 PROT Command OK. Using Private data connection
            statusCode: 200
            readResponse: Elapsed time: 63 millisec
          passive transfer mode
              sendingCommand: PASV
              replyLineQP: 227 Entering Passive Mode (10,48,147,20,109,255).
              commandResponse: 227 Entering Passive Mode (10,48,147,20,109,255).
              statusCode: 227
              readResponse: Elapsed time: 109 millisec
            PassiveHostAddress: ...
            passiveHostAddr: ...
              hostname: ...
              port: 28159
                  hostname: ...
                  port: 28159
                  ssl: 0
                    domainOrIpAddress: ...
                    port: 28159
                    connectTimeoutMs: 60000
                      This is an IPV4 numeric address.
                      Domain to IP address resolution not needed.
                          ai_flags: 4
                          ai_family: 2
                          ai_socktype: 1
                          ai_protocol: 0
                          ai_addrlen: 16
                          ai_canonname: (NULL)
                      connecting to IPV4 address...
                      ipAddress: ...
                        Waiting for the connect to complete...
                        myIP: ...
                        myPort: 50972
                        socket connect successful.
                SO_SNDBUF: 8192
                SO_RCVBUF: 8192
                TCP_NODELAY: 0
              dataConnectSuccess: 1
          setupPassiveDataSocket: Elapsed time: 749 millisec
          sendingCommand: RETR ...
                        success: 1
                  Sending ClientCertVerify message...
                    ModulusLen: 257
                    DLen: 256
                    PLen: 129
                    QLen: 129
                    DPLen: 129
                    DQLen: 129
                    InvQLen: 128
                    signatureSize: 256
                  WindowsError: An existing connection was forcibly closed by the remote host.
                  WindowsErrorCode: 0x2746
                  numBytesRequested: 5
                  Failed to receive data on the TCP socket
                  Failed to read beginning of SSL/TLS record.
                  Failed to read incoming handshake messages. (3)
              Client handshake failed. (1)
              connectionClosed: 0
            ConvertToTls: Elapsed time: 483 millisec
            Failed to convert data connection to TLS
        downloadToOutput: Elapsed time: 1373 millisec
      TotalTimeMs: Elapsed time: 1389 millisec

Thanks for any help/ideas.



I examined this LastErrorText, as well as the LastErrorText you also sent in email. They are different in the point at which the client discovers that the server-side has terminated the data connection. In the case above, the client has received the 1st set of TLS handshake messages from the server, but then discovers the connection to be close when it tries to send the next message in the TLS handshake. In the LastErrorText you sent in private email to support, Chilkat finds the connection closed immediately when it tries to send it's "Client Hello" (which is the 1st message sent by the client in a TLS handshake). Given that the problem is not deterministic, meaning that the server is not closing the connection at the same place each time, such as what would happen if the TLS client (Chilkat) sent an invalid handshake message, I suspect the problem is external. Unfortunately, I don't know what it could be. If it weren't your production system, I would suggest testing with the firewall turned off temporarily (for a very brief time).

I do have a new build you can test, but I don't think it will solve the problem. There is a difference in this build in that it will automatically "re-use" a TLS session for the data connection -- assuming multiple transfers use the same FTP2 object. The term "re-use TLS connection" means that the session key is re-used, and thus the TLS handshake is shorter/faster. The actual TCP data connection is not re-used, but the TLS handshake on each subsequent data connection would be the shortened form if the server allows for TLS session re-use. Maybe this could side-step the problem???

Here are new builds for testing: 64-bit: 32-bit:

PS> A problem such as this, given that you are under support, is best kept in private email. I can post the final resolution once (hopefully) it's solved...