Port refusing connection

[Rick_105]

We are running an EAI application on our HP-UX 11i server which should be able to accept a connection on port 8726. When the sending application attempts to connect, the connection is refused. We put a sniffer on the server and we see a reset being sent from UX box. The port is shown in the netstat -a in the Listening status. I do not know if it is related but when I do a netstat -p I get this

60532 connect requests dropped due to no listener

Any thoughts?

[Tomek Gryszkiewicz]

Maybe you are using more than one IP on this machine, and your server is listening on the other ip?

-Tomek

[Rick_105]

There are 2 NIC's but ony one is enabled.

[Tomek Gryszkiewicz]

Try to telnet to this port - if "connection refused" occurs, means nothing is listening on this port.

[Hari Kumar]

check your /etc/services file for proper initialization of your specified port number,
you your port has been configured for the particular application you will able to do
telnet
if not u will get the connection refused error, the same attempt reflects in your
netstat -p protocol also. Also you can check if large number of drops and refuses present u can check for queue length also.

HTH

[Rick_105]

I got a connection refused. But in the netstat -a I get this

tcp 0 0 *.8726 *.* LISTEN

[Tomek Gryszkiewicz]

That's strange. Is the server which shoul listen on this port running? Try to use lsof -i to determine if something is really listening on this port. Sometimes port is blocked after program crash.

[Hari Kumar]

As the DROP value given by you is high,
the probable settings causing error are
NDD and NDDCONF files
can please check for these values
tcp tcp_conn_request_max
tcp_syn_rcvd_max
u can set these values to large values using
#ndd -set
and also u can clear the stats from lanadmin **if those ndd settoings wont work out.

HTH

[Rick_105]

The tcp_conn_request_max is 4096.
The tcp_syn_rcvd_max is 500.
My guess is these are both default values. How do I determine how high to set these?

[Sergejs Svitnevs]

What does /var/adm/syslog/syslog.log have to say?? Have a look for a line that mentions refused connect.

Regards,
Sergejs

[Hari Kumar]

By looking at the output of either
"netstat -s" or "netstat -p tcp" and looking for the line displaying the number of connection requests dropped due to full queue we can say If tcp_conn_request_max is too small. (this parameter is also called system listen queue depth).
If the number of drops is zero, the value of tcp_conn_request_max is fine. If the value is non-zero, either tcp_conn_request_max is too small or the values the applications are using in their calls to listen() are too small.
The value specified by you is high enough, but still we can find the drops, try for 6000+ value to be set.
max_conn_request_max is also global parameter.
HTH

[Rick_105]

The number of drops from a full queue was only 9. The server has been up 22 days and the statistics have not been reset so I am not sure how big of an issue that is.

There is nothing in the syslog dealing with that port or with a failed connection.

The only other thing that I see that might point to anything is the other connection to the server that resembles this one looks like this in a netstat -a

tcp 0 0 *.8642 *.* LISTEN
tcp 0 0 GHSEGAT2.8642 datagate.4770 ESTABLISHED

[Rgomes]

Hi,

You can check nettl.LOG00* file under /var/adm. But you have to format the file first. Pls see netfmt man pg.

Rgrds
Richard

[Michael Steele_2]

"...60532 connect requests dropped due to no listener..." means you have applications listening on your server but nothing is coming in on that port. The port is not indicated. This error is not related to your question if a firewall is involved. This could be at the router or on the server. If on the server then something like 'inetd.sec' or 'tcp wrappers' would be used.

The 'connection refused' error supports this.

Do a traceroute between nodes and track the router. Are there other IP addresses shown in the traceroute or just is there just a switch? If IP's then go to these nodes and check for firewall applications.

Also, when you use your sniffer the port should be indicated, like with 'tcpdump'.

xxx.xxx.xxx.xxx 8726

[Michael Steele_2]

Oops.
"...This error is not related to your question if a firewall is ...

should read..

This error IS related to your question if a firewall is

[Rick_105]

Let me answer the last couple of posts in this one. there is no firewall in the mix. I am getting a reset packet being sent from the server on the port in question(8726). The topology is from the server to a switch(cisco), to a router (cisco), onto a wan. The connecting server is behind a router on the other side of the WAN. I did the trace route and got the jumps from the server to the switch to our router to their router and then to the server. We are able to make connections to their server to send data there, they just cannot connect to our server to send data back to us.

I also looked at the nttl.log00* file. The last several entries were entries from us unpluging the network cable and repluging it into a hub.

[Duncan Edmonstone]

Hi,

Is the application listener managed by inetd? (i.e. does the application have an entry in /etc/inetd.conf like telnet or ftp) Or is the listener started and managed sperately (like the Oracle listener for example). If started by inetd - check the following:

1. As suggested above, have you checked there is no entry in /var/adm/inetd.sec that only allows access to that service from certain IP addresses?

2. Also have you turned on logging for inetd ? (I'm not at a system right now, but IIRC 'inetd -l' will do this)

If the listener runs seperately I'm not so sure where to go... it appears from your netstat output that *something* is listening on the port, but can you be sure it's your listener? You might want to get hold of a copy of lsof and check this. Otherwise all I can suggest is turning on debugging or additional logging in your application and looking at relevant log files.

HTH

Duncan
HTH

Duncan

[Michael Steele_2]

Yes, at this point only 'lsof' will provide information about the application using the port, for there may be a conflict with that port.

But /etc/services should id this.

Here is 'lsof'.

http://hpux.cict.fr/hppd/hpux/Sysadmin/lsof-4.64/

And the 'telnet ip port' number should succeed. So you have all the tools now.