Transfer files from Alpha to PC with ftp connaction

[Camiel Vanderhoeven]

Hi Aneta,

A lot of ftp clients don't understand the regular VMS ftp server very well. This can be a real pain. I use WS-FTP when FTP'ing from/to VMS. You could download a trial version from http://www.ipswitchft.com/ and try if that works.

Cheers,

Camiel

[Jim_McKinney]

>>On the alpha run ftp to itself and report the results.
> I had run the test, and it works. but from PC no.


Any chance that there's an intervening firewall (or router with port filtering of some sort) that is permitting access to the FTP control port but not its data port? Have you attempted a passive mode transfer?

[Robert Gezelter]

Aneta,

A small amplification to Jon's earlier comment.

A firewall blocking a port often presents as a pair of timeouts: one at the server; and one at the client.

Since FTP uses two connections, the symptoms described in the original post are often caused by blocking the reverse (data) channel.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Don't use FTP. Everybody eventually discovers the protocol design stinks; among its various problems, the protocol is inherently incompatible with modern firewalls. Use sftp, which works better with firewalls, and avoids disclosing your username and password credentials in cleartext, and which allows you to do a no-password login using certificates.

If you want to use ftp, then either open up your firewalls to the ephemeral port range, or remove the intervening firewall(s) entirely, or get a more expensive firewall that can inspect ftp and open the appropriate ports. Or use sftp.

Here's how ftp works, and why it causes problems with its use of ephemeral ports:

http://labs.hoffmanlabs.com/node/530

[Steven Schweda]

> Since FTP uses two connections, [...]

> Have you attempted a passive mode transfer?

As suggested, many FTP clients and servers
offer a "passive" mode to work around this
problem.

Before getting too far off the track, I'd
like to see a transcript of the failing
session (from the Windows client). Perhaps
I'm not paying attention, but I have no idea
where in the FTP session the failure occurs.
"FTP Connection from PC doesn't work" does
not tell me what the user did or what
happened when he did it. If the user can't
get connected at all, then it's pointless to
drag "passive mode" into the discussion.

> Can you get it to work with any other FTP
> server?

Still wondering.

> These are always difficult to diagnose
> remotely.

They are, with no useful information.

> when I try to connect to alpha with
> Internet Explore (ftp://ip adress), I see
> intranet's directories, but I cant open
> them.

Ok, MSIE doesn't understand what it sees, but
it _does_ see something. It appears that it
got connected, and that it returned a file
listing of some kind. Right?

> I used to connect all the time with the
> cmd.

Perhaps something has changed.

It might be helpful to see exactly what you
do "with the cmd", so that we might know what
works and what fails.

Do you have another PC?

[Andy Bustamante]

Aneta,

Another version of the comments above: What ftp client are you using on the Windows system? If it's the native client, change to something that supports passive ftp. WS-FTP or SmartTerm for example.

Another option may be to use Pathworks Lan Manager Server to create a network share on the Alphaserver. That's another can of worms, but once configured is very reliable.


Andy Bustamante

[Steven Schweda]

> [...] or SmartTerm for example.

SmartFTP? I used that, years ago. (It
worked. Better, after they fixed a bug I
reported.)

[Hoff]

Filezilla is my usual suggestion for folks still on Windows.

[Andy Bustamante]

Steven,

SmartFTP also supports sftp and works very well in either command mode or graphic view.

If they had an option to disable the option to store user id/password with a connection I'd be much happier since my other hat has "Security Compliance" on the front.

Andy

[Steven Schweda]

Deviating a little from the main topic, ...

> SmartFTP [...] works very well [...]

One of the big challenges for an FTP client
when dealing with a UCX (TCPIP) FTP server is
that server's mystifying behavior with ODS5
extended file names. I can't remember if the
SmartFTP folks ever put in code to handle
what may be the only FTP server on the planet
which doesn't understand as input the file
names it provides in its own listings.

Luckily, at VMS V6.2-1H3, we don't need to
worry about those newfangled (1999?) features
like ODS5.

Of course, many Web browsers can't even
handle what it does for long ODS2 names. For
example, try a simple command-line FTP client
and HP's latest Mozilla/SeaMonkey SWB on:
ftp://antinode.info/moz_test/
It's sad.