× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. January 2013

Re: Ftping large files w/o timing out

Hi Tim

There are actually 2 timeouts for FTP - only the inactivity timeout is set with CHGFTPA.

Here is help from the IBM i -

quote help time
214-TIME <inactivity> <transfer>: Sets server time-out values for this FTP session.
214- <inactivity> is the inactivity time-out in seconds.
214- <transfer> (optional) is the file transfer time-out in seconds.
214-Example: TIME 900.
214 More information is available in the TCP/IP Configuration and Reference, SC41-5420

I think you need to increase the <transfer> timeout - worth a try - and worth looking it up - it's been a while.

If in an IBM i FTP session, you can run the stat subcommand - it'll give you both timeouts at the bottom of the output.

If in a Windows FTP session, use quote stat (I think) to see the same stuff.

HTH
Vern

On 1/28/2013 11:31 AM, Tim Bronski wrote:
That's where I don't see the PASV/EPSV being relevant. The doc you sent
me describes a problem that's relevant to establishing data connections.
Once a data connection is made then it's irrelevant which command was
used. So, if you're able to create a connection and send a file then
whichever passive command you used works. The issue with large files is
due to timeouts on the control connection when the transfer on the data
connection takes too long. Perhaps something else solved the issue.

On 1/28/2013 6:09 PM, Terry Nonamaker wrote:
Only when sending very large files
... in this case, one file that is 4.9gb and another that is 13.4gb
... otherwise, there is no problems

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Young
Sent: Monday, January 28, 2013 8:47 AM
To: Midrange Systems Technical Discussion
Subject: Re: Ftping large files w/o timing out

Terry,
I this only an issue when sending very large files, or an issue in general
when this condition occurs?

Thanks,


On Mon, Jan 28, 2013 at 11:21 AM, Terry Nonamaker <
TNonamaker@xxxxxxxxxxxxxxxx> wrote:

So, attaching a document did not go so well .....so here's the info


IBM - Disabling EPASV/EPORT in the iSeries FTP Client at R610 and above

www-01.ibm.com/support/docview.wss?uid=nas1dace92df240295dc8625742500565275
1/2

Technote
At R610, the iSeries FTP client supports the EPASV (Extended Passive,
EPSV) command and EPORT (Extended Port, EPRT). The FTP client
defaults to this and, if the server we are connecting to does not, the FTP
client will fail over to Passive mode FTP. However, in some cases, an
error
message is not returned. Most commonly, this is due to a firewall not
allowing or supporting the EPASV /EPORT command, and the establishment
of a data connection will appear to 'hang' with:

229 Entering Extended Passive Mode

In these cases, the EPASV/EPORT commands must be disabled.
The FTP client attempts data connections in the following manner:
Extended Passive
Passive
Extended Port
Port

As a result, if PORT mode is needed, the three preceding data connection
types must first be toggled off. This can be done in one of two ways:

1. On a connection-by-connection basis using FTP client subcommands:
o SENDEPSV - Toggles Extended passive
o SENDPASV - Toggles Passive mode
o SENDEPRT - Toggles Extended Port

Note: The data connection type can also be set (regardless of what the
default behavior is) by using the 0 or 1 switches with the above 3
commands. For instance:
SENDEPSV 1 - would toggle extended passive on
SENDEPSV 0 - would toggle extended passive off

2. On a system-wide basis with the use of data areas:
o CRTDTAARA DTAARA(QUSRSYS/QTMFTPEPSV) TYPE(*LGL)
AUT(*USE) - disables EPASV
o CRTDTAARA DTAARA(QUSRSYS/QTMFTPPASV) TYPE(*LGL)
AUT(*USE) - disables PASV
o CRTDTAARA DTAARA(QUSRSYS/QTMFTPEPRT) TYPE(*LGL)
AUT(*USE) - disables EPO RT with PTF SI33243 applied to the

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Terry Nonamaker
Sent: Monday, January 28, 2013 8:02 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Ftping large files w/o timing out

This is the IBM document I based it on
....sounds like my problem to me
....and, as I said before, it now works just fine

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Bronski
Sent: Monday, January 28, 2013 7:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: Ftping large files w/o timing out

Well that's good...but it doesn't make sense unless we're talking about a
different problem than the one i assumed. PASV or EPSV set up the data
connection (EPSV is really just the ipv6 version of pasv). Once the data
connection is in place it doesn't matter which one was used. If the
problem
was in establishing a data connection for a transfer then I can see how
perhaps the firewall had an issue but after that...

But hey, if it's working...

On 1/28/2013 4:46 PM, Terry Nonamaker wrote:
Switching to PASV mode did make all the difference ......it totally
works now

The EPSV has problems with firewalls
.....PASV does not
.....it is working just like I want it to

Thanks

Terry Nonamaker

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Bronski
Sent: Saturday, January 26, 2013 7:00 AM
To: Midrange Systems Technical Discussion
Subject: Re: Ftping large files w/o timing out

If the timeout is happening after it has been sending for a while then
I don't see any reason why a switch from EPSV to PASV would have any
effect whatsoever.

But, I had discovered in another post about using passive mode (PASV)
......as opposed to the default of ... extended passive mode (EPSV)

That seems to do the trick
....it does not have issues with the firewall now ....no time out
--
Need secure FTP? Forget PASE...get your FREE sFTP here
www.arpeggiosoftware.com
--
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.
--
Need secure FTP? Forget PASE...get your FREE sFTP here
www.arpeggiosoftware.com
--
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.


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




As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.