FIN_WAIT & CLOSE_WAIT

[lafargeadmin]

I have a netstat -an output state FIN_WAIT & CLOSE_WAIT. I am running an real time applications under different server.On the application level it got terminate abnomally.
On the OS level I only find the FIN_WAIT & CLOSE_WAIT state.

Can anyone advice do we require a tcp tuning on buffer to open larger fragments?, How can I tune this tcp parameter?, What is the min & max Value.

[Steven E. Protter]

Shalom,

Tune these parameters and see the list of possible parameters with the ndd command.

The default I believe is 60 seconds.

These problems are often caused by poorly written application code, not system configuration.

/etc/rc.config.d/nddconf to see current default settings.

SEP

[Jeeshan]

check the thread, looks like similar to your requirements

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1031869

[rick jones]

Best to differentiate between FIN_WAIT_1 and FIN_WAIT_2 - the former is an active retransmission state (of the TCP FINished segment) which will be cleaned-up based on the tcp_ip_abort_interval. The second is the one discussed in the referenced post.

[Laurent Menase]

Just a remark,

FIN_WAIT_2 endpoint connected to CLOSE_WAIT endpoint may be something normal.

When an application is using half closed socket
- remsh -n for instance, rcp,....

In that case the CLOSE WAIT side can still send data, when the FW2 can only receive data but not send any.

[lafargeadmin]

This is not what I want. I know it has poorly written application code at the application level. Beside this, I need to prove to the application owner, this is cause by the application. On my end I want to tune the tcp buffer windows to the max.
Can anyone explain what is the tcp parameter name where I can tune with the ndd command?

[rick jones]

Can you expand a bit more on what you mean by "open larger fragments?"

As for showing an application bug, prior to it happening, on the side with CLOSE_WAIT you would want a tusc trace of the system calls showing it either not looking for, or ignoring a read return of zero indicating the remote (Which I presume is FIN_WAIT_2 although you need to confirm that...) has sent a FINished segment.

[lafargeadmin]

Dear Guru's,

The network switch and system's speed setting were causing this issue. I have force it to 100 Full duplex on the switch port and the system lan port. Finally the issue have resolved with the processes are running without error.

Thank's for all your assistant's.

[rick jones]

While duplex mismatch may have led to missing some packets, it seems to have uncovered issues up in the applications as well. Anyhow, if you are happy with the way things are working, good. In the meantime, attached is some boilerplate on autonegotiation you may find helpful.

[lafargeadmin]

Hi Rick,

Thanks Again.