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