SYN_SENT Problem

[Chakravarthi]

Hi all,

I'm using Redhat 7.1 Advanced Server, running a application which sends some data to a Solaris machine on remote end onto a specific port, the link is WAN link, between both the sites i'm using a VPN tunnel,, now the problem is after some time the socket connection goes to SYN_SENT state and it doent try to reestablish the connection, there should not be a problem with the remote end or the firewall/VPN because i'm able to telnet to the remote end using the port which i'm using for the testing, Is there any parameters which i need to change......

Any help

thanks
chakri

[U.SivaKumar_2]

Hi,

Too many connections in SYN_SENT state indicates either one of the below or combination of the below points.

1) Your WAN is very slow. Measure Round trip time of your WAN and increase the bandwidth pipe of your ISP if neccessary.

2) There is some Firewall in between DROPPING the packets silently ( without sending any reset ) from this source server to your destination server.

3) Your source server is sending TCP connection requests to a destination IP address which is unreachable and non-existent.

regards,

U.SivaKumar

[Chakravarthi]

HI shiva,

There only one connection, which gets disconncted and goes to SYN_SENT,

do you have any idea, in firewall what is life time for the Phase 2 proposal COnfiguration, i'm using netscreen 5XP

thanks
chakri

[rick jones]

SYN_SENT is one of the first states of TCP connection establishment. It seems a bit odd to hear someone saying that a connection disconnects and goes to the SYN_SENT state.

Are you perhaps saying that the connection is disconnected, and then a subsequent attempt to connect remains in the SYN_SENT state? That would make a bit more sense, since a given connection cannot drop back to the SYN_SENT state.

Anyhow, in addition to the reasons for being "stuck" (likely simply awaiting the retransmission timer to expire) in SYN_SENT mentioned previously, there can also be a case where the SYN is dropped at the server - when the listen queue on the server is full. With most apps, it is unlikely that the listen queue would fill with just one connection attempt, but if the server application did call listen() with a parm of one or perhaps even zero (I'm a bit fuzzy on the semantics of zero for a listen queue depth) then you might see this with just one connection.

Also, if there was indeed a dropping of the connection, if it was dropped "properly" as opposed to being aborted, there will still be (as there should) a TIME_WAIT state on the end that initiated the drop.

If the client then tries to connect from the same IP address and local port number, a connection cannot be reestablished unless the initial sequence number (ISN) is in the "right" place relative to the TCP window from the previous incarnation of that connection "name" (local/remote IP, local/remote port).

The insistance of some to have "completely random" ISN's means that the likelihood of the SYN being in that range is _not_ 100%. At that point the server may (I'm again a bit fuzzy on the spec here) just decide to discard the SYN. You are then again at a point where you end-up waiting for either TIME_WAIT to expire, or the retransmission limits to be reached.

So, if you have packet traces of the disconnect and subsequent reconnect attempt, and can run netstat on the systems to see if there is a TIME_WAIT you can see if perhaps this is what is happening.

I do not suggest toasting TIME_WAIT - it is there for a reason. However, Solaris does have a rather long TIME_WAIT default of 240 seconds. I personally would be comfortable with a TIME_WAIT length of 60 seconds, but not less than that. The issues of ISN selection would of course still be there, so simply reducing TIME_WAIT would not necessarily "fix" this problem.

Getting the client to connect from a different port number would in theory fix this (assuming of course that th hypothesis as to the problem is correct...).