How to manage SYN_SENT entries returned by netstat -a

[Peter Blinks_1]

server details:

centaur:root:/dc.zeus/centaur> uname -a
HP-UX centaur B.11.00 U 9000/800 607329302 unlimited-user license
centaur:root:/dc.zeus/centaur> netstat -a|grep 9100
tcp 0 1 centaur.55967 166.59.208.33.9100 SYN_SENT
tcp 0 1 centaur.55964 170.127.40.158.9100 SYN_SENT
4e174600 stream 0 0 0 4d179100 0 0

How can we get rid of these entries they are causing unnecessary network traffic and filling log files that collect traffic info.

[James R. Ferguson]

Hi:

'SYN_SENT' is a normal client TCP socket state that is entered after a client issues a connect to a server socket. If acknowledged by the server, the client socket state will proceed to ESTABLISHED.

Regards!

...JRF...

[Peter Blinks_1]

Hi James,

Thanks for the quick reply.
Any idea what happens if the destination IP is unreachable, can we get rid of this connection, it seems to be retrying every second indefinately and filling up network log files that are sniffing the network.

Thanks
Richard
MIS Unix Team
WorldCom

[Peter Blinks_1]

Fixed:

Finally got to use lsof with the right options which pinpointed the process pid.

# lsof -i @170.127.14.14:9100

COMMAND PID
hpnpf 8472

Turns out printers were turned off, moved to different subnet and jobs that were stuck before never cancelled.

Thanks
Richard

[rick jones]

As pointed-out a connection in SYN_SENT state is one where the application has called connect() but the remote TCP has not yet responded to the sent SYNchronize TCP segment with a SYN|ACK of its own.

On HP-UX 11, a connection in this state will remain for tcp_ip_abort_cinterval milliseconds before aborting if no response is received.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt
[ ADMIN Note: Broken link removed]

The SYN segments will be retransmitted with the same exponential backoff of a "normal" TCP data segment, and as such, I suspect that the load two of them could put onto a network would be negligible.

Now, this is based on what TCP will try to do - applications may impose other constraints and so may give-up and retry sooner.

BTW, besides the very useful lsof tool having shown you that these were for a print job, the port number of 9100 is the "well known" port number used by all (?) the HP print server products for TCP/IP printing