COPY/FTP via a different port?

[Lester Dreckow]

Hi,

Is there a way for COPY/FTP or DIR/FTP to connect to an ftp server (non-VMS) via a different port? Is there a logical name or something?


- this works ...

$ ftp 192.168.201.132 4121
220 Microsoft FTP Service
Connected to 192.168.201.132.
[...]


- but can we make this work? ...

$ dir/ftp 192.168.201.132"theusername thepassword"::
%TCPIP-E-FTP_NETERR, I/O error on network device
-SYSTEM-F-REJECT, connect to network object rejected
$
$
$ tcpip show version

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - ECO 2
on an HP rx3600 (1.59GHz/9.0MB) running OpenVMS V8.3-1H1

$

Thanks,
Lester

PS. The frequently posted concerns with ftp are acknowledged.

[Steven Schweda · Accepted solution]

> Is there a way [...]

I know of none. If you're trying to fetch a
file, then wget seems to allow a ":port_nr"
specification in an URL. For example, these
both do the same thing:

$ wget "ftp://user:PASS@alp/login.com"
$ wget "ftp://user:PASS@alp:21/login.com"

namely, something like the following. (Note
the ":21".)

--2010-12-16 22:19:16-- ftp://user:*password*@alp/login.com
=> `login.com'
Resolving alp... 10.0.0.9
Connecting to alp|10.0.0.9|:21... connected.
Logging in as user ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD not needed.
==> SIZE login.com ... done.
==> PASV ... done. ==> RETR login.com ... done.
Length: 9710 (9.5K) (unauthoritative)

92% [==================================> ] 8,943 --.-K/s in 0.001s

2010-12-16 22:19:17 (8.74 MB/s) - `login.com' saved [8943]


Or, specifying a non-default port (where no
one is listening):

alp $ wget "ftp://user:PASSWD@alp:421/login.com"
--2010-12-16 22:13:47-- ftp://user:*password*@alp:421/login.com
=> `login.com'
Resolving alp... 10.0.0.9
Connecting to alp|10.0.0.9|:421... failed: connection refused .

So it appears to be following instructions.

If you're trying to send a file, then you may
be out of luck. I may have an old
VMS-adapted version of (the much less
popular) "wput" lying around, but I don't
know if it could deal with ":port_nr"
notation. It might take a while to scrape
together a source kit. (I looked briefly at
wput about six years ago, but, having COPY
/FTP, it never seemed to be worth much
effort.)

[Robert Gezelter]

Lester,

A quick check of some examples on a slightly older version of TCPIP (7.3-2/TCPIP 5.4) narrows the issue somewhat.

$ COPY/FTP 127.0.0.1"username password"::LOGIN.COM X.TMP

works as expected.

$ COPY/FTP 127.0.0.1:21"username password"::LOGIN.COM X.TMP

results in an attempted login as "anonymous".

Going into FTP itself, the OPEN command clearly supports the following syntax:

$ FTP
FTP> open 127.0.0.1
...

To avoid starting/stopping TCP (or hacking with the FTP server), adding a port number on the end, to wit:

$ FTP
FTP> open 127.0.0.1 7465

(Where 7465 is an unused port) produces the expected result.

Admittedly with all of the caveats of a 3:00 AM check, it seems that FTP client has no problem with the construct, but that the command definition for COPY/FTP and DIR/FTP has a definition that does not quite accept the syntax.

Admittedly, I do not have time today to undertake to look in detail at the DCL definitions for COPY/FTP and DIR/FTP gratis.

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

[Hoff]

#import

AFAIK, no. The alternate port specification on the DCL-level /FTP syntax is quite certainly undocumented, and AFAIK, there is no such alternate port selection mechanism implemented within the command processing.

I've tried what would be the classic DCL encoding for this, and errors resulted:

$ dir /ftp www.example.com:4121"user pass"::
$ dir /ftp/port=4121 www.example.com"user pass"::

And this verb syntax doesn't look promising:

$ search -
SYS$COMMON:[SYSUPD]COPY.CLD -
ftp,port/window=11

You might be able to tunnel into the box and get to the ftp server that way, which also would solve several problems. This either in addition to the odd configuration, or as a wholesale replacement for it.

I'd be interested in hearing the rationale and constraints for this Windows Server ftp configuration; without that detail, this looks to be among the worst of many possible file transfer implementation schemes.

(I run Unix servers for these sorts of tasks and not Windows Server boxes, so the tools and features are undoubtedly different; I'm not current on whatever Windows features and limitations might exist here.)

[John Gillings]

Hi Lester,

No hacks that I'm aware of. I tend to use COPY/FTP and DIRECTORY/FTP whenever possible, but sometimes they just don't cut it.

If you can't create a static script, and want to avoid generating temporary files, you can use PIPE to feed commands into FTP. For example, implementing CREATE/DIRECTORY/FTP:

$ SET NOON
$ PIPE WRITE SYS$OUTPUT "mkdir ''ftp_dir'" | -
FTP/INPUT=SYS$PIPE:/USERNAME="''ftp_user'"/PASSWORD="''ftp_pswd'" 'ftp_addr' | -
COPY SYS$PIPE: NL:

the copy to NL at the end is just to surpress noise, and for some reason >nl: didn't work (can't remember the details).

In your case just include the non-standard port in the ftp_addr symbol.

Obviously the first stage of the pipe can be more complex. If it gets too long, or needs conditionals to generate, use a procedure - "@GENERATE_FTP_COMMANDS"

[Lester Dreckow]

Thanks gentleman. I needed to confirm before asking the client “why that port?”.

Thanks Steven for the wget idea.

Thanks John, your pipe examples are always interesting.

I guess a COPY/FTP/PORT= syntax would be the ideal.

Regards,
Lester Dreckow