topic Re: FTP interrupted or timeout in Operating System - HP-UX

FTP interrupted or timeout

James A. Donovan — Wed, 28 Jun 2000 15:25:26 GMT

Hi,

Hoping someone can help me out with this. One of our sister divisions sends us files via FTP 5-6 times a day. Everything goes smoothly except for the run just after 7:00 AM. Is it possible to setup a cron job or something using nettl to trace the ftp sessions? If so, how as I've not used the utility before.

I've attached the error log the ftp sender is receiving, as well as the only entry I see in my syslog.log. I use wu_ftpd Version wu-2.6.0(2) as my ftp service via inetd.
I find it very odd that I am not seeing a corresponding FTP LOGIN message just prior to the FTP session closed.

Any help appreciated....

Entry from my syslog.log:
Jun 28 07:16:33 firebird ftpd[13209]: FTP session closed

Sender's error log:
IBM FTP CS/390 V2R5 1998 230 22:59 UTC
FTP: using TCPIP instead of INET
Connect to ?
162.49.67.45 (EXIT
Connecting to: 162.49.67.45 port: 21.
Connection to server interrupted or timed out.
FTP Return Code = 10000

Re: FTP interrupted or timeout

Mike McKinlay — Wed, 28 Jun 2000 15:42:34 GMT

What I notice about the time is that it occurs in the morning. Unless this is a dedicated circuit (we run FDDI between a UNIX system and our MVS system to avoid this problem, of course, they're in the same building :), you may just be running into some contention for network bandwidth as users log in to the 390 and other systems (UNIX workstations, NT and Win95 systems, and so on).

You'd need to put a sniffer on the network to make sure.

What network segments these systems reside on and what other resources are contending for the same bandwidth are things you should consider.

Are these systems in the same building or even the same timezone? Is there a frame relay network between them or a dedicated leased line?

Find out more about the network environment and you'll likely find your culprit.

Re: FTP interrupted or timeout

James A. Donovan — Wed, 28 Jun 2000 17:20:20 GMT

Got a little more info now. I asked them to resend trying an alternate IP address and I got some more info in the system log.

Jun 28 09:21:07 firebird ftpd[14710]: FTP LOGIN FROM 43.144.64.1 [43.144.64.1],
selftp
Jun 28 09:22:09 firebird ftpd[14736]: getpeername (/opt/wu_ftpd/sbin/ftpd): Sock
et operation on non-socket
Jun 28 09:22:29 firebird ftpd[14710]: FTP session closed

Anyone know what "Socket operation on non-socket" is supposed to mean?

Re: FTP interrupted or timeout

Berlene Herren — Wed, 28 Jun 2000 18:47:43 GMT

Hi Jim,
What patch level do you have for FTP? PHNE_20714 has fixes for both the client and server. Do you think adjusting your TCP Keepalive values would help?

ndd -set /dev/tcp tcp_keepalive_interval 600000
ndd -set /dev/tcp tcp_ip_abort_interval 2000

This sets it 10 minutes...

Berlene

Re: FTP interrupted or timeout

James A. Donovan — Wed, 28 Jun 2000 19:37:28 GMT

I have that patch installed, and the values for those intervals are already well above 10 minutes. In fact I probably should reduce them. However, do you think there could be a benefit in upping the value of tcp_conn_request_max? Its current value is 20. At about the time of the failures, the system IS getting connection requests from users logging into the application. (This system houses an Oracle database to support Siebel.)

Re: FTP interrupted or timeout

Phil Gregory_1 — Thu, 17 Aug 2000 08:42:55 GMT

Jim,
Is the transfer coming through or into a firewall?
I have seen instances where some firewalls (and ftp servers) reject connections when the ftp port request is over a certain limit, say 5000. Ftp increments the port number each time it starts a session. MVS systems doing a lot of ftp transfers will soon hit this limit.

Re: FTP interrupted or timeout

James A. Donovan — Tue, 22 Aug 2000 18:35:27 GMT

I don't know about the port number issue, but I was able to at least get a partial capture of the packets being sent to the FTP server. tcpdump for some reason is unable to capture the traffic going out to the client on interface /dev/dlpi0. The packets seem to indicate that the problem sessions complete the 3-way handshake to initiate the connection, but that the first packet sent to the server from the client after that has the F and P flags set, followed about 60 seconds later by a R packet from the client side.