Scripted FTP Hangs on Second Transfer
Posted: Tue Jul 23, 2019 6:01 pm
I am working issue with the built-in Windows FTP command line client connecting to CoreFTP. The server is Windows 2016, fully patched. Core is version 1.2, build 589.42, 64-bit, Enterprise edition. The config.dat file and certs folder were moved over from a Windows 2003 server running an older 32 bit version of CoreFTP, but that instance was only handling encrypted SFTP, with plaintext FTP being handled by IIS.
The customer is using a set of script files to transfer a series of PDF files. So, in a particular folder, it will have file1.ftp, file1.pdf, file2.ftp, file2.pdf, etc. Each one of those .ftp files is a text file with their username, password, a binary command, a CD command to change to a folder off of their home folder, a put command for the corresponding .pdf file, and then a quit command to finish.
The customer will then use a foreach command to call the Windows built in FTP client, effectively giving a series of scripted FTP commands:
ftp -s:file1.ftp ftp1.example.com > result.log
ftp -s:file2.ftp ftp1.example.com > result.log
And so forth to iterate through the folder, with each ftp text file putting up a correspondingly named pdf file. The first FTP command issued logs in, issues the port command, and successfully uploads the first pdf file. However, on the second FTP command, the transfer hangs.
Looking at the transfer in a packet capture, I can see that in the first ftp command that the FTP client issues the port command, and then the server issues the SYN command back to start its three way TCP handshake. However, when the client issues the port command for the second transfer, the server does not issue a SYN packet to start a separate three way handshake.
Are there any settings changes that can be made that would ensure that each transfer from this client would get the SYN command sent to start its FTP transfer?
Thanks.
The customer is using a set of script files to transfer a series of PDF files. So, in a particular folder, it will have file1.ftp, file1.pdf, file2.ftp, file2.pdf, etc. Each one of those .ftp files is a text file with their username, password, a binary command, a CD command to change to a folder off of their home folder, a put command for the corresponding .pdf file, and then a quit command to finish.
The customer will then use a foreach command to call the Windows built in FTP client, effectively giving a series of scripted FTP commands:
ftp -s:file1.ftp ftp1.example.com > result.log
ftp -s:file2.ftp ftp1.example.com > result.log
And so forth to iterate through the folder, with each ftp text file putting up a correspondingly named pdf file. The first FTP command issued logs in, issues the port command, and successfully uploads the first pdf file. However, on the second FTP command, the transfer hangs.
Looking at the transfer in a packet capture, I can see that in the first ftp command that the FTP client issues the port command, and then the server issues the SYN command back to start its three way TCP handshake. However, when the client issues the port command for the second transfer, the server does not issue a SYN packet to start a separate three way handshake.
Are there any settings changes that can be made that would ensure that each transfer from this client would get the SYN command sent to start its FTP transfer?
Thanks.