Using the latest prelease 145pr3. We are uploading a 129mb file using the Curl MBS plugin on a Windows machine. The file uploads and we can verify the file size on the remote FTP server is correct, but the Curl Perform method return code is 28, which indicates a time out. Since the return code is not zero, our app tries to upload again. We rely on the return code to know whether or not the upload was successful.
The Curl website indicates a curl option called -m, --max-time . But, the MBS plugin does not have an option with this exact name. It has OptionTimeOut and OptionTimeOutMS. We set the OptionTimeOut to 1800 seconds. The transfer takes place in much less time than that, but the Perform method still returns error 28.
old SSL session ID is stale, removing
Server certificate:
subject: *
start date: *
expire date:*
issuer: *
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
We are completely uploaded and fine
Remembering we are in dir “customer/output/”
SSLv3, TLS alert, Client hello (1):
FTP response timeout
control connection looks dead
Closing connection 0
SSLv3, TLS alert, Client hello (1):
The FTP server has a user setting “Idle Timeout”. It was set to 3 minutes. We changed to 20 minutes but it did not change anything. I guess, rather than paying attention to the return code, we can look into the debug data and see if the sentence “We are completely uploaded and fine” is there. But, that seems like a hack.
We originally tried SFTP but found Curl that is known to be very slow with SFTP transfers. It took a while to get FTPS to work. We ended up having to add these: oCurl.OptionFTPSkipPasvIP = True and oCurl.OptionFTPUseEPSV = False
If that fixes the problem then something is closing part of the FTP connection while the file transfer is in progress.
This is usually a firewall (software / hardware) or a router that does not understand FTP correctly. Once the file transfer starts the port 21 comms connection becomes inactive for a period of time so it can be closed by something in between the client and server. Enabling TCP KeepAlive causes the TCP stack to send a heartbeat on a regular basis so that it appears active.
Thank you. I’ve been struggling with this error 28 timeout too just testing it now. I thought it was something I was doing since everything worked fine for a single download, but had random problems when FTPing multiple downloads.