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.

iFtpPut Error 12003

Question:

I have a script I have been using for years without a problem. But now this line is failing: 
x=iFtpPut(h2,f2,"xyz.txt",0,@ASCII)
h2 is a a successful iHostConnect at this point in the script.

f2 is valid file.

I suspect there may be something about the ftp server that changed and is causing the failure, but when I manually connect to it I am able to manually transfer the local "f2" file with no problem.

I tried using iGetLastError to obtain further error information. 

rs = iFtpPut(...)
err=iGetLastError()
errmsg = iGetResponse()
If rs != ""
   Pause("Error", StrCat(err , " " , errmsg ) )
   Exit
EndIf
I get... 
12003 0: 200 Type set to A
200 PORT command successful
421 No Transfer Timeout (300 seconds): closing control connection.

Answer:

Interesting the Server is sending back the error 421 No Transfer Timeout (300 seconds): closing control connection.

Does your code specify the control_send_timeout or control_Recieve_timeout of the FTP server using iOptionSet?
If so, try removing or increasing the values.

Are you specifying @FTP iHostConnect?
If so, try the @FTPPASSIVE option instead.

Are you specifying the optional keep-alive parameter for iFtpPut?
If not, try specifying @TRUE.

Please try each change individually and let us know what resolves the issue for you.

User Reply:

I am not calling iOptionSet in that code.

The parameter to iHostConnect was set to @FTP and I changed it to @FTPPASSIVE and the transfer did go through.

However, the file created on the server was not a binary duplicate of the original (as it is when I transfer it manually). I changed the ASCII parameter to BINARY. It worked! Not sure why anything had to be changed suddenly, since it was working fine for years. But I'll take it!

Answer:

Here is an explanation about why those changes to your script were probably necessary:

Active Vs. Passive FTP Connections
There are two common modes for FTP connections: Active and Passive.

Active-mode FTP Connections
Referred to as "client-managed" because the client sends a PORT command to the server (over the control connection) that requests the server to establish a data connection from TCP Port 20 on the server, to the client, using the TCP port that is specified by the PORT command.

Passive-mode FTP Connections
Referred to as "server-managed", because after the client issues a PASV command, the server responds to that PASV instruction with one of its ephemeral ports that will be used as the server-side port of the data connection. After a data connection command is issued by the client, the server connects to the client using the port immediately above the client-side port of the control connection.

NOTE: The most common problem encountered when you use FTP over the Internet results when you attempt transfers through a Network Boundary Securing Device (NBSD) such as a proxy, firewall, or Network Address Translation (NAT) device. In most cases the NBSD allows the control connection to be established over TCP 21 (that is, the user can successfully log on to the FTP server), but when the user attempts a data transfer such as DIR, LS, GET, or PUT, the FTP client appears to stop responding because the NBSD is blocking the data connection port that is specified by the client. If the NBSD supports logging, you can verify port blocking by reviewing the deny/reject logs on the NBSD.

A quick summary of the pros and cons of active vs. passive FTP is also in order:
Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side.

Luckily, there is somewhat of a compromise. Since admins running FTP servers will need to make their servers accessible to the greatest number of clients, they will almost certainly need to support passive FTP. The exposure of high level ports on the server can be minimized by specifying a limited port range for the FTP server to use. Thus, everything except for this range of ports can be firewalled on the server side. While this doesn't eliminate all risk to the server, it decreases it tremendously. See Appendix 1 for more information.

Ascii Vs. Binary FTP Transfers
There are two common modes for transferring files via FTP: Ascii and Binary.

Ascii mode
Transfers files as 'text'. Examples of ascii files would be .txt, .asp, .html, and .php files.

Binary mode
Transfers files as raw data. Examples of binary files would be .wav, .jpg, .gif, and mp3 files.

NOTE: If you are transferring files from Windows to a Unix based server, Ascii mode will strip out the CR (carriage return) characters found at the end of each line. You may notice that the file you uploaded is smaller than your local file. This is completely normal and is nothing to worry about. 

Article ID:   W17620

Filename:   iFtpPut Error 12003.txt
File Created: 2008:11:25:13:00:28
Last Updated: 2008:11:25:13:00:28