Re: FTP problem

I remember fighting this with Bell South, but for the life of me can't
remember what we did (it was in a previous life) to get it to work, IIRC we
actually "stumbled" upon the answer, I'll try and see if I have any notes on
it lying around at home....I remember it taking "months"

On 8/14/06, Steve McKay <mckays@xxxxxxxxxxx> wrote:

Yep, tried passive - actually, their server puts the session into passive
mode even if I don't specific 'PASV 0'.

I'm really not so much after suggestions as I am an opinion on the
accuracy
of the tech support person's statement about IBM's FTP client and NAT.

Thanks,

Steve

"Chris Bipes" <chris.bipes@xxxxxxxxxxxxxxx> wrote in message
news:mailman.4121.1155582678.2610.midrange-l@xxxxxxxxxxxxxxx
> Have you tried to set Passive mode?
>
>
> Christopher Bipes
> Information Services Director
> CrossCheck, Inc.
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve McKay
> Sent: Monday, August 14, 2006 12:02 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: FTP problem
>
> We are attempting to FTP a file from a bank using the FTP command -
>
> FTP RMTSYS('bank.ftpserver.com') PORT(20021) SECCNN(*SSL)
>
> This connects to a Sterling Commerce FTP server on the bank's mainframe.
>
> Once connected, I can provide user ID and password, move around in
> directories, and pretty much do anything I want to except list contents
> of directories and retrieve files.  When I try to actually retrieve a
> file, the session hangs and eventually gives me a "No response from FTP
> server"
> message.
>
> The odd thing is, I am already connecting to another bank which uses
> Sterling Commerce and have been retrieving files from them for several
> months.  I have gone back and forth with the bank's (semi-)technical
> support personnel to describe the problem as a firewall configuration
> issue based on many messages here on Midrange-L to no avail.  Today I
> received this e-mail from the (not very) technical support person:
>
> "The problem is that the FTP control data is encrypted as it comes
> through the firewalls, so it cannot be read to do the IP "natting" at
> the firewall.
> Most third-party clients handle this by storing the original control
> address and using it during the transmission. Native FTP programs such
> as MSDOS and IBM's FTP do not allow for this and uses each control block
> as it is sent.
> There is also a feature called Clear Control Channel that allows the
> userid and password to be sent encrypted, then all other data exchanged
> over the control channel to be sent as clear text. In our case, this
> would allow the firewall to see the IP address and correctly "nat" it to
> the proper IP. All data sent over the data channel will remain
> encrypted. According to our vendor, this is a feature normally found
> only in third-party FTP software, and they are fairly certain this
> feature would not be available on the default AS/400 operating system
> FTP software."
>
> This response seems highly incorrect in light of the fact that we are
> already FTPing from another bank using Sterling Software.
>
> Is their response correct?
>


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