FTP issue / FIN_WAIT_2

[Tom Horan]

Hi,
I've got a HP Workstation running HPUX 11 try to ftp files over a dial-on-demand ISDN line through a firewall to/from an NT 4.0 server.

I'm getting problems like the following

200 PORT command successful.
150 Opening ASCII mode data connection for testfile.txt(148155 bytes).

(long wait in here before I eventually hit Ctrl+C)

abort: Socket operation on non-socket
abort: Bad file number
421 Service not available, remote server has closed connection
421 Service not available, remote server has closed connection

After the connection stops I then get the following listed from a netstat

tcp 0 0 myhost.domain.49585
dest-nt-host.ftp-data FIN_WAIT_2

Anyone seen anything like this ? Its driving me up the wall .....

Thanks,
Tom

[Johan Gjestvang]

Hi Tom, looks like the ftpd
on the NT does't run properly or the ftp-data port (20) is blocked in the firewall.

Cheers,
Johan

[Cheryl Griffin]

Tom,
This won't help the ftp "abort: socket" messages but may help with the fin_wait issue.

PHNE_19375 (now PHNE_26771) added a feature that can help clear up FIN_WAIT_2 issues.

After this patch (or its supersede) has been installed you can run ndd to get the timeout:
# ndd -get /dev/tcp tcp_fin_wait_2_timeout

If this is zero, it means that there is an infinite wait for the connection to be dropped.

Set the timeout to a minute with:
# ndd -set /dev/tcp tcp_fin_wait_2_timeout 60000

Cheryl

[Neil Dixon]

DO you need to run in passive mode?

[Tom Horan]

Johan,
I have my suspicions regarding the NT ftpd alright. As for ftp-data port, it is open, as some transfers will work.

Neil,
Tried passive mode, same thing happens.

Thanks guys.

Tom

[Cheryl Griffin]

Have you checked hostname resolution (forwards and backwards)? There are several references to this on the web, O'Reilly said "This type of problem may also be caused a failure to resolve the host addresses properly, especially if using Reverse Address Resolution Protocol (RARP). The simple answer to this is to list all relevant host names and IP addresses in the /etc/hosts files on each machine."

[Ron Kinner]

There is a patch from microsoft for tcpip.sys which stops the Fin_Wait_2 problem.

It hasn't been released so you have to beg microsoft for it.

http://support.microsoft.com/support/kb/articles/Q254/9/30.ASP

LAST_ACK is what you see on the other end when your end says FIN_WAIT_2



I put the patch on my website:

http://www.geocities.com/heartland/9670/

Look down at the bottom of the page for tcpip patch.

Ron

[Tom Horan]

Cheers for the reply Ron,
I came up with that solution myself alright, unfortunatley the NT side is not under my control and they insist that they do not need that patch, and they are not seeing any equivelant problems as described in the Technet article.

Thanks,
Tom

[Ron Kinner · Accepted solution]

They may be right about not needing the patch. It certainly won't keep ftp from working. What the problem does is overload the HP with a bunch of connections stuck in FIN_WAIT_2 until eventually it crashes or refuses new connections.

When I reread your problem I thought "firewall problem" but passive doesn't help and the FIN_WAIT_2 on port 20 proves that it was able to connect to you so it's not likely that it's the firewall.

It looks like the problem might be in your machine. Can you FTP to another machine on the network? If so it might be a DNS or host file problem with the NT box. If not it may be a software issue. Are your patches uptodate?

Is your own ftpd turned on? Can you ftp to yourself and transfer files?

Ron

[rick jones]

i would suggest getting a copy of tcpdump onto the HP-UX box and tracing the packets between you and the NT box. start this before the FTP is started and see what happens.

FIN_WAIT_2 means we've sent a FIN, and it has been ACKed and we are waiting for a FIN from the remote. if the remote is poorly behaved, it might send a RST instead of a FIN and that may be lost and we will stay in FIN_WAIT_2.

however, the arbitrary fin_wait_timeout (or whatever it is called) should not be necessary. after tcp_keepalive_detached_interval (ndd) the HP stack will start sending keepalive probes. if those probes are not answered within tcp_ip_abort_interval the FIN_WAIT_2 endpoint will be terminated.

if there is a firewall that is still responding to the keepalives after the remote is toast, the firewall is broken and needs to be fixed.

[Tom Horan]

Ron,
Thanks for the reply.

I can ftp around internally fine - ie, between 'myhost' and a second internal host. FTP'ing to and from the host work fine, I've tried this with few large files and with many small files, no problems.

Now, my machine is quite out of date, its an old workstation and there is barely any room on it, so the chances of getting a patch bundle onto it are slim.

I'm in the process of getting a spare D class, up to date with patch bundles, moved into my DMZ area to swap with the workstation to try and rule out the HP side of things.

I'll let you know how I get on with this.

Rick,
Thanks for the reply, I'll save using the tcpdump for a few days (sound complicated !! ;) )but I'll keep it in mind.

Thanks,
Tom