Client cannot open a connection with tcp port

[manoj_pu]

Hello All,

I am administering a site they have HP9000 N-class servers running hp-ux 11.0,and client server based application. Sometimes the application leaves a particular port in "LISTEN" status with out establishing connection with client when it starts their application on that particular port. If I change that port with another one, client will get ESTABLISHED connection. Then after if I revert back to old port then the old port also will function properly.

Can any have idea on this please reply me it will help me a lot.

Thanks in advance.

[Darrell Allen]

Hello,

I don't understand your question very well. Perhaps you can clarify it, particularly:

"If I change that port with another one, client will get ESTABLISHED connection. Then after if I revert back to old port then the old port also will function properly."

When a server process starts, it opens a socket on the system on which it is running. The socket (identified as IP address and port number) listens for connections from clients. So, when a server process starts you should be able to see a socket for that process with "netstat -a" that is in LISTEN. After a client process opens a connection with that server socket you will see it ESTABLISHED.

"netstat -a" will display a line for each socket open on the system. For established connections you will see the socket pair (server socket and client socket) displayed.

Note that "netstat -a" without the -n parameter will resolve names for hosts and services.

A server does not establish a connection to a client. Clients establish connections to servers.

Please give us more information on the problem.

Thanks,
Darrell

[manoj_pu]

Hello

It is like this when application starts in the server it assign a socket with a port 7051. Some times client will unable to connect on this particular port (7051). At that time if I changed port 7051 to 9014 and restart application, clients will be able to connect with the port 9014. If I revert back that is changing port 9014 to the old one-7051. Then with the old port also clients will be able to connect.

Why clients required these sockets resetting to connect the application in the server?

Thanks for immediate reply

Manoj

[harry d brown jr]

Manjou,

The problem you are describing is an application issue. If this is a purchased product then you should contact your vendor with the issue. If it is written by your comapny, then I'd contact the programmers and have them fix their code.

You could, while you are waiting for a response from either your vendor or your programmers, find out what patches you need.

Go to the Patch area, and do the custom patch manager instructions. And then install your patches, this way no one can point fingers at you :-))

live free or die
harry

[Darrell Allen]

Hi Manoj,

Is another application using port 7051? Are the clients on the same subnet? What error do the clients get when the connection does not get established?

Darrell

[Roger Baptiste]

<>

This seems to be an application issue. The application is not releasing the port 7051 , so you are not able to use it ; But when you switch over to 9014, it seems to break or clear the old connection on 7051. That's why you are able to reuse the 7051.
Recheck this with the application folks.
Do a netstat -a >/tmp/netstat.$$ after each of the above steps and do a
#grep -e 7051 -e 9014 /tmp/netstat.* to
confirm it.

HTH
raj

[Ian Dennison_1]

Does your application you are talking with (and the one you are talking to) have a variable setting for timeout of the Interface or Program you are running? Also look at a lower level (Network configuration, polling interval and timeout perhaps?)

I have experienced a similar problem on an HP box where an NT Application was tying up a port by constantly trying to re-establish the connection under the port. The UNIX server had stopped using it and could not re-estblish the concection.

Perhaps ask the other person to check out if they are also tying up ports. It sounds like it is the remote system that is at fault.

Share and Enjoy! Ian

[Charles Harris]

Hi,

This sounds familiar. We have noticed problems with web applications in particular exhibiting this sort of behavour.

Usually what happens is the app closes un-cleanly and leaves your port in a state of FIN_WAIT. When you restart the app on another port, which is availabe it's okay. The original port then either times out or clears the orginal port.

You should try the following:

Stop the app so that the port jams up. Run a netstat -an | grep ".1024" to see what state its in. If it's a FIN_WAIT or a TIME_WAIT state try the following :-

ndd -set /dev/tcp tcp_fin_wait_2_timeout 1

This should clear your fin wait port within a min. Which should allow you to restart the app.

ndd -get /dev/tcp tcp_time_wait_interval can also be reduced in the same manner as above. The optimal settings for these params are usually found on you app's help and tuning page

Hope this is of some use!!!

Good Luck,

-ChaZ-

[IT Response]

Verify that there are not any PID's on that port. To do this you need to download lsof from the internet and run ./lsof -i | grep port_number. It may be that the application is still running on that port, when you try to start it it fails because the ports busy..or it assumes its busy.

You can downlaod it from this web page

http://hpux.cs.utah.edu/