login about faq
0
1

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:

  • Passive = true
  • AuthTls = false
  • Ssl = true
  • I call SetSslClientCert, passing in the certificate loaded from the Windows Certificate Store
  • After connecting I set PassiveUseHostAddr = true

The error log follows...

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

Message: ChilkatLog:
  GetFile:
    DllDate: Jul 31 2014
    ChilkatVersion: 9.5.0.43
    UnlockPrefix: ...
    Username: ...
    Architecture: Little Endian; 64-bit
    Language: .NET 4.5 / x64
    VerboseLogging: 1
    ProgressMonitoring:
      enabled: yes
      heartbeatMs: 0
      sendBufferSize: 65536
    --ProgressMonitoring
    AutoGetSizeForProgress: 0
    downloadToFile:
      localFilename: ...
      downloadToOutput:
        ModeZ: 0
        BinaryMode: 1
        pbsz_protp:
          sendCommand:
            sendingCommand: PBSZ 0
          --sendCommand
          readCommandResponse:
            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
          --readCommandResponse
          sendCommand:
            sendingCommand: PROT P
          --sendCommand
          readCommandResponse:
            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
          --readCommandResponse
        --pbsz_protp
        setupDataConnection:
          passive transfer mode
          setupPassiveDataSocket:
            sendCommand:
              sendingCommand: PASV
            --sendCommand
            readCommandResponse:
              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
            --readCommandResponse
            PassiveHostAddress: ...
            passiveHostAddr: ...
            dataConnect:
              hostname: ...
              port: 28159
              socket2Connect:
                connect2:
                  hostname: ...
                  port: 28159
                  ssl: 0
                  connectSocket:
                    domainOrIpAddress: ...
                    port: 28159
                    connectTimeoutMs: 60000
                    connect_ipv6_or_ipv4:
                      This is an IPV4 numeric address.
                      Domain to IP address resolution not needed.
                      AddrInfoList:
                        AddrInfo:
                          ai_flags: 4
                          ai_family: 2
                          ai_socktype: 1
                          ai_protocol: 0
                          ai_addrlen: 16
                          ai_canonname: (NULL)
                        --AddrInfo
                      --AddrInfoList
                      connecting to IPV4 address...
                      ipAddress: ...
                      connect:
                        Waiting for the connect to complete...
                        myIP: ...
                        myPort: 50972
                        socket connect successful.
                      --connect
                    --connect_ipv6_or_ipv4
                  --connectSocket
                --connect2
              --socket2Connect
              socketOptions:
                SO_SNDBUF: 8192
                SO_RCVBUF: 8192
                TCP_NODELAY: 0
              --socketOptions
              dataConnectSuccess: 1
            --dataConnect
          --setupPassiveDataSocket
          setupPassiveDataSocket: Elapsed time: 749 millisec
        --setupDataConnection
        sendCommand:
          sendingCommand: RETR ...
        --sendCommand
        convertDataConnToSsl:
          convertToTls:
            clientHandshake:
              clientHandshake2:
                processHandshakeRecord:
                  processHandshakeMessage:
                    processIncomingCertificates:
                      loadX509DerAlt:
                        success: 1
                      --loadX509DerAlt
                    --processIncomingCertificates
                  --processHandshakeMessage
                --processHandshakeRecord
                sendCertificateVerify:
                  Sending ClientCertVerify message...
                  RsaDerToKey:
                    ModulusLen: 257
                    DLen: 256
                    PLen: 129
                    QLen: 129
                    DPLen: 129
                    DQLen: 129
                    InvQLen: 128
                  --RsaDerToKey
                  signSslSig:
                    signatureSize: 256
                  --signSslSig
                  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)
                --sendCertificateVerify
              --clientHandshake2
              Client handshake failed. (1)
              connectionClosed: 0
            --clientHandshake
            ConvertToTls: Elapsed time: 483 millisec
            Failed to convert data connection to TLS
          --convertToTls
        --convertDataConnToSsl
        downloadToOutput: Elapsed time: 1373 millisec
      --downloadToOutput
      TotalTimeMs: Elapsed time: 1389 millisec
      Failed.
    --downloadToFile
  --GetFile
--ChilkatLog

Thanks for any help/ideas.

asked Aug 31 '14 at 11:08

Scott%20Mitchell's gravatar image

Scott Mitchell
111


Scott,

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: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-9.5.0-x64.zip 32-bit: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-9.5.0-win32.zip

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...

link

answered Sep 01 '14 at 08:42

chilkat's gravatar image

chilkat ♦♦
11.8k316358420

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×131

Asked: Aug 31 '14 at 11:08

Seen: 1,118 times

Last updated: Sep 01 '14 at 08:42

powered by OSQA