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.
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: GetFile: DllDate: Jul 31 2014 ChilkatVersion: 188.8.131.52 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.
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...