WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WIL Extenders
WinInet
plus
Samples from Users

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

iFtpGet Wininet Error 12031

Question:

I am getting the WinInet error 12031 when i attempt to get an file from my FTP server using iFtpGet.

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.
"

Answer:

The Wininet error 12031 indicates: ERROR_INTERNET_CONNECTION_RESET The connection with the server has been reset.

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.

User Reply:

As usual I a completely amazed at the quality of response from you guys. Nowhere else like this forum. It occurs to me that I have had problems using FTP Commander when not in passive mode with this server. I am using my laptop which has McAfee firewall installed.

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:

  • xp pro sp1 PC with no firewall same result.

  • @FTPPassive with fire wall same result

  • @FTPPassive XP Pro sp1 no firewall same result
I think it must be the Globascape secure ftp server v1.0 which gives inconsistent results. I tried using my own remote server running Gene6 and it goes through fine, no errors! I recreated the same directory stucture on both servers and used the same file. ho hum. Thanks for all your help 
Article ID:   W16891

File Created: 2007:07:03:14:26:44
Last Updated: 2007:07:03:14:26:44