Re: FTP Fails with "426 Transfer cancelled"

The client timeout setting is in the client script:

(from the v6r1 ifo center - search "ftp client timout")

There are two different values for the one command T1 or T2, and it sounds like you need T2

DEBUG (Change Client Time-Out Limit Values)
The DEBUG i5/OS® FTP client subcommand changes the client timeout limits when the default timeout values are not long enough for a data transfer to be completed successfully. You only need to change these values in situations where network traffic or other conditions cause transfer times to become quite large.
FTP client subcommand
DEBug T1 | T2 [ value ]
T1
Change or display the FTP client time-out limit for reading server replies. If the FTP client does not receive an expected server reply within this time limit, the client will close the control connection to the server.
T2
Change or display the FTP client time-out limit for transferring data. If the FTP client does not receive an expected data connection response within this time limit, the client will close the data connection to the server.
value
The time-out limit in seconds. This value must be a positive number greater than zero. When you omit this value, the client displays the current value of the time-out limit.
For example:
DEBUG T1 900
This value sets the client time-out value for server replies to 900 seconds.

jim franz


----- Original Message ----- From: "Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, January 17, 2012 1:53 PM
Subject: Re: FTP Fails with "426 Transfer cancelled"

hi Sam,

The remote session records 10054, if I read correctly what the remote
support guys sent me. (There is a slight language barrier.) I think
10054 means "connection reset by peer".

Correct, 10054 is Windows Sockets error code WSAECONNRESET, which does
indeed mean "Connection reset by peer".

Typically, this error message ("connection reset") implies that the
socket was disconnected in a way that would lose data. So data may have
been sent (by one side or the other) and never received. That's the
difference between "connection reset" and other methods that indicate
that the connection has ended.

Our network guy suggests that we are timing out somewhere in the
transfer because the remote system isn't getting back to us quickly
enough.

Errr... It seems rather unlikely that a timeout would generate a
WSAECONNRESET. Bear in mind that the error is occurring during the
transfer of data on the data channel -- it's not occuring in the command
channel. (If the command channel had been reset, you couldn't receive a
"426 Transfer Cancelled" message.) Since the data channel has no user
interaction, it's purely a program-to-program transfer of file data, I
don't see how it could time-out?

I guess a time-wait timeout might cause this. Take a look at the value
you have for CHGTCPA TCPCLOTIMO(xxx).

Where would I configure how long we wait before cancelling the
transmission?

Is CHGFTPA the right place to look? If so, all I see there related to
time is INACTTIMO, which is set to 300.

It sounds to me that you are using the client (rather than the server)
on IBM i. CHGFTPA pertains to the server.

I don't think there's a client-side timeout setting. Since the
client-side is interactive, you'd normally just hit an F-key to abort
when you're tired of waiting.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.