stuck FTP: TCPIP$FTP_KEEPALIVE question

[Peter Humaj]

Hello everyone,
is there anybody who dealt with this kind of problems?

I have
HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer DS25 running OpenVMS V7.3-2


every few seconds I run ftp client to remote Unix machine and download some files.
In last few weeks ftp client (once in 2-3 days) gets stuck (there may be network packet losses or too much router traffic ..)

Ftp's socket looks like this:

TCPIP> sh dev bg5010 /ful
Device_socket: bg5010 Type: STREAM
LOCAL REMOTE
Port: 57507 21
Host: 10.12.65.1 10.11.1.131
Service: FTP

RECEIVE SEND
Queued I/O 0 0
Q0LEN 0 Socket buffer bytes 0 0
QLEN 0 Socket buffer quota 61440 61440
QLIMIT 0 Total buffer alloc 0 0
TIMEO 0 Total buffer limit 491520 491520
ERROR 0 Buffer or I/O waits 1 0
OOBMARK 0 Buffer or I/O drops 0 0
I/O completed 1 0
Bytes transferred 0 0

Options: None
State: ISCONNECTED PRIV
RCV Buff: WAIT
SND Buff: None


(it state is "ISCONNECTED", 1 IO completed, but it shows 0 bytes received. when I tried to connect to non-existent ftp server, status of socket was "ISCONNECTING", 0 IO completed.
When succesfully connected to ftp server, status is "ISCONNECTED", 2 IO completed, 51 bytes transferred (initial "Hello" from ftp server).

So it seems to me, that ftp client sends SYN, receives SYN ACK (thus considers connection established) and sends ACK to ftp server, which probably gets lost...

When I manually disconnect socket
TCPIP> discon device bg5010
ftp client unfreezes ..


First I tried to change general tcp options to timeout the socket:

tcp_keepalive_default=1
tcp_keepidle=20
tcp_keepintvl=20
tcp_keepcnt=2

it didn't help. Then I found in documentation
http://h71000.www7.hp.com/doc/732final/6526/6526pro_036.html

that ftp uses its own logical, so I set
DEFINE /SYSTEM/EXEC TCPIP$FTP_KEEPALIVE 1

still ftp client got stuck.

Then another version of documentation (older) on
http://www.myths.com/pub/doc/openvms/721final/6526/6526profile_019.html

says that TCPIP$FTP_KEEPALIVE should be TRUE or FALSE.


My question: has anybody met this kind of problem of stuck FTP client? Is there any way to find out what socket options are set on a 'stuck' socket?
Which version of setting TCPIP$FTP_KEEPALIVE is really valid?

Thank you .. at least for reading

And greetings from small country in central Europe .. currently under 1 meter of heavy but melting snow :-)

[paolo barila]

Hi Humaj
and welcome to this forum!
I'm sorry I didn't have your kind of error but...
Think about recent changes in your systems that can affect this problem.
When I have problems with ftp through firewall I switch from active to passive ftp, or better I use sftp,scp also on OpenVMS.

Pablo

[Peter Humaj]

Hi Paolo,
so far, I'm not aware of any changes in network, but we are investingating this (only a part of network with VMS is under my control, Unix server is on a different segment).
And yes, I'm using passive ftp, but it makes no difference - it's the "control" channel (to port 21) that gets stuck. And it happens once every few days (and ftp client is run approximately once in 5-10 seconds) .. as I said previously, there may be network problems (packet loss on routers) that I cannot influcence but have to cope with.

I start to think about running ftp client as a batch job and create a watchdog task which would kill him if it does not terminate in some decent time .. but before using violence, I'd like to try some more ..reasonable solution :-)

Thank you for answer anyway
Best regards,
peter

[melvyn burnard]

posted in wrong forum, moved to Open VMS forum

[labadie_1]

Could you post
$ ucx sh service ftp/ful
$ mc authorize sh tcpip$ftp

[Volker Halle]

Humai,

TCPIP V5.4 is up to ECO 5 since JUN-2005. So maybe try to do yourself a favor and upgrade to the latest ECO first.

It would be a waste of time, if you would try chasing a problem, that may have been already solved.

Volker.

[Peter Humaj]

Thank you Volker Halle,

ECO 5 has solved the problem (together with DEFINE /SYSTEM/EXEC TCPIP$FTP_KEEPALIVE 1)

I've been able to make ftp client stuck by connecting to a linux server which had a firewall configured like this:

iptables -A INPUT -p tcp --dport 21 -j DROP
iptables -A INPUT -p tcp --dport 21 --syn -j ACCEPT

So it accepted first SYN packet, sent answer, but dropped all other packets to port 21.

And actually even ECO1 was enough to solve the problem

Thanks for help everyone!

[Peter Humaj]

Solution was found (ECO patch), details are in my last comment