Values and explanations for operation in EZA2589E
This topic lists and describes the values for operation in EZA2589E.
- Initial Connection
- Timer
- MYOPENTIME
- Explanation
- The FTP client is trying to establish a connection with the FTP server. Either the TCP connection has not completed yet or the initial reply from the server has not been received.
- User Response
- Ensure the remote server responds to a ping request. The value of MYOPENTIME can be increased to allow more time for the server to send the initial reply. If the problem recurs, contact the system programmer.
- System Programmer Response
- If there are firewalls between the FTP client and FTP server, ensure the firewalls are allowing FTP traffic from the client IP address to the FTP server for the port being used. A packet trace of the failing transfer shows whether the TCP connection has been completed, the IP addresses being used, and any replies sent by the server.
- Initial IPv6 connection
- Timer
- MYOPENTIME
- Explanation
- The FTP client is trying to establish a connection with an FTP server using an IPv6 address. Either the TCP connection has not completed yet, or the initial reply from the server has not been received.
- User Response
- Ensure the remote server responds to a ping request. The value of MYOPENTIME can be increased to allow more time for the server to send the initial reply. If the problem recurs, contact the system programmer.
- System Programmer Response
- If there are firewalls between the FTP client and FTP server, ensure the firewalls are allowing IPv6 FTP traffic from the client to the FTP server for the port being used. A packet trace of the failing transfer shows if the TCP connection has been completed, the IP addresses being used, and any replies sent by the server.
- Waiting for data connection
- Timer
- INACTTIME
- Explanation
- The FTP client is waiting for the FTP server to establish a data connection. A PORT or EPRT command, shown in a previous EZA1701I message, has been sent to the FTP server indicating the IP address and port on which the client is listening. The server should initiate a TCP connection to the FTP client. This connection has not completed yet.
- User Response
- Increase the value of INACTTIME and try again. Contact the system programmer if the failure recurs.
- System Programmer Response
- Ensure that active data connections or PORT or EPRT commands are
allowed by any firewalls between the client and server. Take a packet
trace of the failure to determine whether the remote FTP server has
attempted the connection to the FTP client. If the packet trace does
not show an SYN packet arriving from the server to the specified IP
address and port, investigate the FTP server and the path to the FTP
client to determine whether the connection is being blocked. If the
FTP client is not responding to the SYN packet, take a CTRACE (with
options TCP and INTERNET) and a packet trace. Send these to IBM® customer service. The FTP client
could also be configured to use firewall friendly data connections
by issuing the locsite fwfriendly subcommand before
the get or put subcommand or
by coding FWFRIENDLY TRUE in FTP.DATA. This might allow the data connection
to complete because it causes the client to send a PASV or EPSV command
instead of a PORT or EPRT command. Guideline: The PORT or EPRT command sent to the server determines the port and IP address the FTP server connects to. For EPRT, the format is EPRT |X|Y|Z|, where X is the address family, Y is the IPv4 or IPv6 address and Z is the port. For the PORT command, the port being used must be calculated. For PORT, the format is a,b,c,d,x,y, where a.b.c.d is the IPv4 address, and (x * 256) + y is the port number.
- Sending a command
- Timer
- INACTTIME
- Explanation
- The FTP client has timed out sending a command to the FTP server. This indicates that the TCP layer is unable to transmit data to the remote server.
- User Response
- Contact the system programmer.
- System Programmer Response
- Take a packet trace to investigate the TCP traffic between the two hosts.
- Sending ABORT command
- Timer
- INACTTIME
- Explanation
- The FTP client has timed out sending an ABORT command to the FTP server. This indicates that the TCP layer is unable to transmit data to the remote server.
- User Response
- Contact the system programmer.
- System Programmer Response
- Take a packet trace to investigate the TCP traffic between the two hosts.
- Receiving data
- Timer
- DATACTTIME
- Explanation
- The FTP client is waiting for data from the FTP server on the data connection. A full buffer of data has not arrived within the DATACTTIME seconds, or the FTP client was interrupted by the user before a full buffer of data arrived. The FTP client issues a recv() call, which returns only when its buffer is full or when the connection has ended. The FTP client uses a default buffer size of 180K. The FTP client is dependent on the data connection closing cleanly. This informs the FTP client that all the data has arrived from the server. If the connection does not close cleanly, this message is issued.
- User Response
- Increase the DATACTTIME to allow more time for data to arrive. If the failure recurs, contact the system programmer.
- System Programmer Response
- Take a packet trace to investigate the data transfer. The packet
trace should be analyzed for conditions which would slow down the
transfer, such as retransmitted packets or decreasing window sizes.
Increasing the DATACTTIME can allow the FTP client more time to recover
from these types of network issues. DATACTTIME should also be increased
for transfers over low-bandwidth connections, such as dialup. If
the packet trace shows that the connection does not close cleanly
(for example, the FIN packet is not properly acknowledged), the remote
server might need to be investigated as well.Tip: For best results, specify the Session option when formatting the packet trace.
- Sending data
- Timer
- DATACTTIME
- Explanation
- The FTP client has timed out sending data to the FTP server over the data connection. The FTP client sets a timer to the value of DATACTTIME seconds before issuing a send call. If the send does not complete in that time period or the FTP client is interrupted by the user, the FTP transfer fails. This timeout can be caused by a slowdown in the transfer, such as network congestion or the remote machine not accepting data.
- User Response
- Increase the value of DATACTTIME to allow more time for the data transmission to occur. If the failure recurs, contact the system programmer.
- System Programmer Response
- Take a packet trace to investigate the data transfer. Analyze
the trace for causes of a slowdown. For slow networks, such as dialup,
increase the DATACTTIME. If the packet trace shows many retransmitted
packets, investigate the network to determine why packets are being
dropped.
The window size advertised by the FTP server can also slow down the connection. If the FTP server is advertising a small window size, investigate the server to determine whether the window size can be increased. If the FTP server is very busy, causing the window size to decrease or even go to 0, increase the DATACTTIME to allow more time for the server to handle the data.
Tip: Specify the Session option when formatting the packet trace for best results.
- Waiting for reply
- Timer
- INACTTIME
- Explanation
- The FTP client is waiting for an expected reply from the FTP server on the control connection. The timer has expired, or the user has interrupted the FTP client before a reply was received. The reply from the FTP server tells the FTP client whether the previous command was successful or not. When a reply is not received, the FTP client must assume that the command was not successful.
- User Response
- INACTTIME could be increased to allow the FTP server more time to reply. If the failure recurs, contact the system programmer.
- System Programmer Response
- For long running jobs, firewalls might time out the control connection due to inactivity. FTPKEEPALIVE can be coded in FTP.DATA to cause the TCP layer to send KeepAlive packets on the control connection. The firewalls can also be configured with longer inactive times. Use a packet trace to determine whether the replies arrive at the FTP client. If the packet trace does not show the FTP reply, determine where the reply is being rejected. Otherwise, contact the IBM Support Center to investigate the packet trace.
- Sending command to SOCKS server
- Timer
- INACTTIME
- Explanation
- The FTP client has timed out sending a command to the SOCKS server. This indicates that the TCP layer is unable to transmit data to the SOCKS server.
- User Response
- Contact the system programmer.
- System Programmer Response
- Take a packet trace to investigate the TCP traffic between the two hosts. Use the locstat subcommand to determine the IP address of the SOCKS server.
- Waiting for reply from SOCKS server
- Timer
- INACTTIME
- Explanation
- The client is trying to establish a control or data connection to the FTP server through the SOCKS server. The client has sent a connection establishment SOCKS command to the SOCKS server and is waiting for a reply. The FTP client has timed out or been interrupted while waiting for the reply. The SOCKS server might not have replied because it was not processing SOCKS commands in a timely fashion; it was waiting for the remote FTP server to respond, or the SOCKS server did not process the FTP server response in a timely fashion.
- User Response
- INACTIME can be increased to allow the SOCKS server more time to process commands. If the message occurred while trying to build a data connection through the SOCKS server, issuing the locsite fwfriendly subcommand prior to the put or get subcommand might allow the data connection to be built. If the failure recurs, contact the system programmer.
- System Programmer Response
- Verify with the administrator of the SOCKS server that the server is receiving the commands and processing them in a timely fashion. The IP address of the SOCKS server can be determined with a locstat command. Ensure that the SOCKS server can communicate with the FTP server. Firewalls between the SOCKS server and the FTP server must allow FTP connections and FTP data connections. Take a packet trace to trace the network traffic between the FTP client and SOCKS server. An FTP client trace, enabled by coding DEBUG SOC(2) and DUMP 85 in FTP.DATA, shows the SOCKS commands sent to the server. If a firewall is blocking the data connection, issuing the locsite fwfriendly subcommand prior to the put or get subcommand or specifying FWFRIENDLY TRUE in FTP.DATA might allow the data connection to complete.
- Establishing data connection through SOCKS server
- Timer
- MYOPENTIME
- Explanation
- The FTP client is trying to establish a TCP connection to the SOCKS server so that a data connection can be established to the FTP server. The client has already successfully logged into the FTP server using the SOCKS server. The TCP connection has not completed. The SOCKS server might be too busy to accept new connections in a timely fashion.
- User Response
- The value of MYOPENTIME can be increased to allow more time for the SOCKS server to accept the connection. If the failure recurs, contact the system programmer.
- System Programmer Response
- Contact the administrator of the SOCKS server to determine whether the SOCKS server is accepting new connections. Take a packet trace to verify that the SOCKS server is not responding to the connection attempt.
- Initial connection to SOCKS server
- Timer
- MYOPENTIME
- Explanation
- The FTP client is trying to establish a TCP connection to the SOCKS server so that a control connection can be established with the FTP server. The TCP connection has not completed. The SOCKS server might be too busy to accept new connections in a timely fashion.
- User Response
- Use the locstat subcommand to determine the IP address of the SOCKS server. Verify that the SOCKS server is reachable by pinging the server. Increasing the value of MYOPENTIME allows the SOCKS server more time to accept the connection. If the problem recurs, contact the system programmer.
- System Programmer Response
- Verify that the SOCKS server is reachable. Contact the administrator of the SOCKS server to determine whether the SOCKS server is accepting new connections. Take a packet trace to determine whether the TCP connection to the SOCKS server completes. Use the locstat subcommand to determine the IP address of the SOCKS server; the port number of the SOCKS server is always 1080.