FTP problem

[ianvt]

We are encountering a problem with ftp, when you ftp from a VMS host to another host, but cannot connect, the job does not abort. It tries to connect and holds up the STATUS$BATCH queue until the job is deleted.

Has anyone encountered this before?

[Wim Van den Wyngaert]

If a TCP connection cannot be established within a period of time, TCP will time out the connection attempt. The default timeout value for this initial connection establishment is 75 seconds. The TCP_KEEPINIT option specifies the number of seconds to wait before the connection attempt times out. For passive connections, the TCP_KEEPINIT option value is inherited from the listening socket. The value of TCP_KEEPINIT is an integer between 1 and n, where n is the value for the systemwide parameter tcp_keepinit . The default value of the systemwide parameter tcp_keepinit , specified in half-second units, is 150 (75 seconds).
To display the values of the systemwide parameters, enter the following command at the system prompt:

$ sysconfig -q inet


Is the setting way too high on your site ?

Wim

[Wim Van den Wyngaert]

BTW : we have it on 40 (* 0.5 seconds).
Tested it and ftp stops indeed after 22 seconds (to a node that is down).

Wim

[ianvt]

Hi Wim

The TCP_KEEPINIT value is 150. Attached is the output of $sysconfig -q inet.

Thanks
Ian

[Wim Van den Wyngaert]

And how long is ftp in "hang" ? And what kind of problem did you have / was the remote node up ?

You can try a tcptrace to find out if what it was doing.

Could you post sys$specific:[tcpip]sysconfigtab.dat to see what was changed compared with the d4efaults ?

VMS / TCP version ?

Wim

[Hoff]

There's not enough detail here for a particular response (eg: IP stack and stack version, OpenVMS version and platform, and a small demonstration or reproducer with the commands could all be useful here); this could easily be some timers or some firewall or such.

As for an alternative guess, this could (also) be an attempt to script an ftp transfer here rather than using the DCL command COPY /FTP (and this command assuming the box is running V6.2 or later with a compatible IP stack), and that there's some sort of a DCL coding error here. There are various ways to get an ftp transfer job to hang, and timers are just one possibility.

Then there's that ftp is a protocol-level problem and a security problem and a firewall problem, but that's fodder for another discussion. sftp is my preferred choice for use on an open network...

[ianvt]

Here is some more info:
The ftp "hangs" until aborted. The problem with the remote host is unknown.

HP TCP/IP Services for OpenVMS Alpha Version V5.4 on a hp AlphaServer GS1280 7/1150 running OpenVMS V7.3-2.

type sys$specific:[tcpip]sysconfigtab.dat gives error:
%TYPE-W-SEARCHFAIL, error searching for SYS$SPECIFIC:[TCPIP]SYSCONFIGTAB.DAT;
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

Example of the script:
$ ON ERROR THEN GOTO ERROR
$ @ACK$PROC:NAT-BATCH-SETUP
$ FTP XXX.XX.XX.XX /USER=XXXXXX/PASSWORD="XXXXXXX"
EXIT
$ @ACK$PROC:NAT-CHECK-STATUS $STATUS SELF
$ IF STATUS .NES. "0" THEN GOTO ERROR
$ @ACK$PROC:NAT-JOB-END NONE
$ @ACK$PROC:CHANGE-JOB-STATUS LOG461U P AXP2READY
$ @ACK$PROC:CHANGE-JOB-STATUS LOG461C P AXP3READY
$ EXIT
$ERROR:
$ @ACK$PROC:NAT-JOB-ABORT
$ @ACK$PROC:CHANGE-JOB-STATUS LOG461C P AXP3READY

[Wim Van den Wyngaert]

Sorry it's SYS$SPECIFIC:[TCPIP$etc]SYSCONFIGTAB.DAT;

Wim

[Wim Van den Wyngaert]

And what's the other side of the connection (HW, version OS) ? Any firewalls ?

Wim

[Wim Van den Wyngaert]

Have you got
DEFINE /SYSTEM/EXEC TCPIP$FTPD_KEEPALIVE 1

I just tested after doing ucx set servi /sock=keep. That's accepted but doesn't work. But the logical works.
Have the impression that keepalive for the initial connection always works. And I guess too that your remote site answered but the connection was lost. And without the logical it hangs forever. Note that with the logical you still have to wait a very long time before it aborts.

This is the contents of my config to avooid this long timeout.

inet:
# detect broken connection after 5 minutes instead of 2 hours
tcp_keepcnt=5
tcp_keepidle=120
tcp_keepintvl=120

Wim

[Wim Van den Wyngaert]

Or even better : DEFINE /SYSTEM/EXEC TCPIP$FTP_KEEPALIVE 1
(this is for the client, in your case the vms ftp).

Here I read that TCP default are not honoured.
http://h71000.www7.hp.com/doc/83final/6526/6526pro_041.html#ftp_logicals_sec They use a default timeout of 15 instead. Don't know if that doc is correct.

Just love this open stuff where any programmer can do what he likes.

Wim

[ianvt]

sys$specific:[tcpip$etc]sysconfigtab.dat contains:

#
# TCP/IP Services for OpenVMS V5.1
# sysconfig parameter file
#
nfs:
tcp_threads=8
udp_threads=8

vfs:
vnode_age=120

The remote node OS is Windows, not sure about firewall.
Attached are the TCPIP logicals defined on the system.

[Wim Van den Wyngaert]

I wonder why they put the version in the config file ...

I would go for enabling keepalive as in my last post. The keepalive logical and the config file settings (apply them in the file and restart tcp) or do
sysconfig -r inet tcp_keepcnt=5
etc.

But then restart ftp service (disable + stop/id *ftp* + enable).

It's not clear which parameters are used by the ftp client. I suspect the config file settings.

I would also take a trace of the ftp session to diagnose the hang.

$ tcptrace /pack=10000/prot=tcp/fu/out=x.lis dest_node
and post that.

Wim

[Wim Van den Wyngaert]

And add /port=21 to the tcptrace if you have other traffic to that node.

Wim

[Willem Grooters]

> The remote node OS is Windows

What Windows: desktop, server, version?

AFAIK, the average desktop windows only has an FTP client, not a server. FTP TO such a machine will fail. I don't know wether it will actually hang of stop immediately.
There may be a FTP server instaleld - I know that IIS as delivered with older Windows evrsions, includes a FTP server.

If it's a Windows Server box, check if FTP is enabled and actually reacting.

It may be possible that the VMS box does connect to the FTP server, but the returning traffic does not arrive, due to bad routing or a firewall blocking the traffic. I've seen both.

Are you running passive mode?

I'm not sure on this, but I kind of remember that 2 ports are involved in FTP: 20 and 21. It may be something to look into as well

[ianvt]

I've got more info: I'm not sure what version of windows the remote node is, but it is connecting via a WAN connection some 1300km away. You can FTP from the command line to the remote node from a windows or VMS client.
The script runs every 2 hours and does not "hang" every time. It seems to me that it might be a bad WAN line. The keepalive logical and config file settings will be changed later today. And then we will have to wait and see if the problem still occurs.

Thanks for the help so far. Ian