Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Here is a clip of the trace file:
getfile=iFtpGet(conhandle,remote_srcfile,zsFileOnPC,0,@BINARY) (1712) VALUE=> 0 if getfile==0 (1712) IF DO==>TRUE errmess=strcat("iGetLastError: ",iGetLastError(),@CRLF,"iGetResponse: ",iGetResponse()) (2894) VALUE=> "iGetLastError: 12031 iGetResponse: 0: 200 Type set to I. 200 Command okay. 550 /Data-OUT/Sage/Master/ACM/ACMN071.zip: No such file. 150 Opening BINARY mode data connection for /Data-OUT/Sage/Master/ACM/ACMN071.zip. 226 Transfer complete. 23735 bytes transferred. 23735 bps. "
Now what exactly does this error mean?
Some digging revealed the following:
1.) The firewall does not support clients using passive mode, so the problem was happening using active mode FTP.
2.) The problem was observed when calling FTP functions that open a data port, including iFtpFindInit, iFtpFindNext and iFtpGet.
But some further digging revealed that it was the firewall software that the FTP server was behind that was resetting the command channel connection established on port 21. The reset actually happens at the TCP/IP stack level, without the FTP server being aware.
So is the connection being reset? Well it seems that you can set up your firewall to sniff for FTP PORT commands to check two things:
1.) That the IP address specified in the PORT command matches the IP address of the client side of the connection that connected to the command port on port 21. This is reasonable.
2.) That the port # specified in the PORT command is not on a long list of known ports. This is what causes the problem, and here is why:
Some FTP commands require a secondary data port be opened. In the case of active mode FTP, Wininet.dll uses the network stack to find a free port in the range of 1024-5000 or greater depending on what OS you are running and the setting a particular registry key. If you watch IP activity with a network analyzer you can see that network stack appears to allocate ports using an increasing # for each subsequent allocation That makes sense, but the problem is some of these ports #s (in fact MANY of these ports) are registered. See http://www.iana.org/assignments/port-numbers.
They are registered but that doesn't mean they are in use on the client machine (and it is obvious that registered ports in the range of 1024-n collide with port #s that the OS may dynamically allocate if the ports are not in use at the time that an application dynamically allocates a port).
So firewall rules such that if the FTP client selected a registered port, even though that port happens to be free on the client, the firewall will reset the command channel connection (on port 21). So at least in this case ERROR_INTERNET_CONNECTION_RESET means that server side of the connection reset the command channel connection (but not by the FTP server, by the firewall).
What does this mean?
If your FTP server supports it. I recommend using @FTPPASSIVE in the iHostConnect statment. See if that resolves the issue.
IF your FTP doesn't support @FTPPASSIVE or the @FTPPASSIVE option doesn't solve your problem, then the best thing to do is re attempt the ftp operation (iFtpGet). So off hand, and lacking more details from MS, I would also suggest doing the same if the error 12030 ERROR_INTERNET_CONNECTION_ABORTEDThe connection with the server has been terminated. Obviously place some limit on retry attempts if you are concerned about it looping forever, but the error suggests to me that the TCP/IP command channel (typically on port 21) has been disconnected for whatever reasons (a firewall explicitly disconnecting, a dropped modem line, a network routing failure) and you should try to reconnect and continue.
What is odd is that this error does not occur when issuing ftp commands from the command prompt. Native FTP must do something different.
My test results are:
Article ID: W16891
File Created: 2017:07:28:13:58:47
Last Updated: 2007:07:03:14:26:43