FTP errors during data connection establishment for the z/OS FTP client

Content

During a typical FTP connection, messages flow back and forth between the z/OS FTP client and the server across the control connection (this is the connection usually established on port 21). However, whenever data is transferred, FTP opens a new connection called the data connection. Commands which result in the opening of a data connection include LS, DIR, GET, MGET, PUT, and MPUT. When trying to establish the data connection, errors may arise, most commonly manifested as an FTP reply such as 425 Can't open data connection or 425 Unable to open data connection. You also may receive message EZA1636I *** I can't open a data-transfer connection:


Steps to follow to resolve FTP errors during data connection establishment for the client:
1. Determine whether your data connection is passive or active. This can be done from within the client by issuing the LOCSTAT subcommand and looking for the FW-friendly message.

1.1 The LOCSTAT command will generate numerous messages. Look for one of the following:
• EZA2818I Data connections for the client are firewall friendly. If you see this message, proceed to step 2
• EZA2819I Data connections for the client are not firewall friendly. If you see this message, skip to step 4.

2. If you see EZA2819I - issue LOCSITE FWFRIENDLY (see IP User's Guide and Commands). Note that, if you are using a secure connection, you should issue LOCSITE EPS4 instead.

3. Reissue whatever command failed to see if this resolves the problem. If not, proceed to step 4.

4. If the command still fails, or you are already firewall friendly, take a packet trace and client trace. First, start the packet trace facility. Detailed instructions for obtaining a packet trace can be found in the Technote How to Collect PKTTRACE and CTRACE on z/OS. If this is a high-volume system, be sure to reference the section on "Packet Trace Parameters" on how to filter tracing based on IP addresses and ports.

5. The z/OS FTP client trace should be activated with options BAS, TIM, and FLO. This can be done by issuing the following FTP subcommand before starting the failing data transfer:

DEBUG FLO TIM BAS

6. If this is an interactive FTP (from the TSO command line or OMVS shell) the output of the trace will be sent to the screen. If this FTP is issued via a batch job, the debug output will be sent to SYSOUT DD.

7. Recreate the problem and deactivate the traces.

8. You will now need to perform trace analysis. Begin this by browsing the client trace and locating the time that the timeout occurred. Obtain the timestamp from the message. Determine the port on which the data connection is being opened by finding the PORT command (if this is an active data connection) or the PASV response (if this is a passive connection). The text for both of these messages will be a string in the format of u,v,w,x,y,z. This can be interpreted as follows:

8.1 The IP addressed to which the data connection will be opened is u.v.w.x.
8.2 The port to which it will be opened can be calculated using the following formula:
(y x 256) + z.
8.3 At this point, you have identified the timestamp, the IP address, and the port to which the data connection will be opened.

9. Open the packet trace in IPCS. Format the trace using the command:

CTRACE COMP(SYSTCPDA) LOCAL FULL OPTIONS((SESSION))

This command formats the trace into a summary for each IP connection.

10. Find the summary that represents the failing connection by looking for an FTP connection which encompasses the time stamp from the client. Use the combination of the port, the IP address, and the timestamp to ensure you have the correct summary. Here is a sample of what you will see:

Local Ip Address:                             128.117.214.7           
Remote Ip Address:                           128.117.10.244           
                                                                       
                                                                       
Host:                                 Local,          Remote           
 Client or Server:                  Unknown,         Unknown           
 Port:                                   21,            1095           
 Application:                        telnet,                           
 Link speed (parm):                      10,              10 Megabits/s
                                                                       
Connection:                                                            
 First timestamp:                 2007/08/24 10:21:54.688167           
 Last timestamp:                  2007/08/24 11:46:16.591480

11. Scroll down past the summary to the individual descriptions and examine the approximate timestamp obtained from the trace.

12. Investigate the reasons the remote server may not be responding. Some of the things you can look for include:

No SYN ACK being returned by the remote server, in this example.

   TcpHdr  IO F        Seq        Ack RcvWnd  Data Delta Time       TimeStamp
1      S    O    965574368          0 368640     0   0.000000 10:44:43.727489
2      S    O    965574368          0 368640     0   2.000000 10:44:45.727489
3      S    O    965574368          0 368640     0   4.000000 10:44:49.727489

Because no SYN ACK is seen inbound from the remote server, either the remote server is not responding, or the client's SYN packet was lost before it reached the server. Possible causes for this lost SYN include a firewall that is preventing connections from being opened, or a router that is discarding packets. To further diagnose this problem, take a network trace at various points on the network concurrently with a packet trace. You can then compare the network trace output to the packet trace to determine on which network segment the packet was lost. For example, consider the following route between an FTP client and server:
SERVER ]--A--[ ROUTER ]--B--[ FIREWALL ]--C--[ CLIENT

If a network trace taken on segment C shows the client's SYN packet, but a network trace on segment B does not, then investigate the firewall to determine why it is dropping the packet. It could be a problem with the port range being used by the remote server application. If the remote server is z/OS FTP, see the section on Determining the FTP server's port range below. Check to see if the port is included in the allowed port range of the firewall. Similarly, if the SYN packet is seen in segment B but not A, then investigate the router. A network trace on segment A capturing the SYN packet warrants investigation on the remote TCP/IP stack. Contact the appropriate service team.

The client's SYN resulted in a reset from the remote TCP/IP stack, another possible reason. This will appear in the packet trace as follows:

   TcpHdr  IO F        Seq        Ack RcvWnd  Data Delta Time       TimeStamp
1    S      O    965574368          0 368640     0   0.000000 10:44:43.727489
2        R  I            0  965574368 368640     0   0.000134 10:44:43.727623

This indicates that either a firewall is not allowing connections, or that the remote FTP server has not established a listen on the specified port. Investigation using network traces, as described above, will help isolate the source of the reset.

13. If you need further assistance or diagnostic support, contact IBM service with the network trace, client and packet trace available.