Hi,

I'm observing an issue with Linux(2.3), where is not responding to a SYN after a normal close. I checked the netstat and the connection doesn't exist. That means the connection is not in FIN_WAIT or TIME_WAIT state. The client app uses the same port and ip for the connection. On of my observation is that srever accepts the connection after 2-3 minutes not before that.

What i have observed is the SYN packet is not reaching the application. Do you think of any reason? How to debug this issue.

Thanks
Jijo

Attached Trace.
1. Client close the connection and reopen immediately. Working fine.
2. Client close the connection and reopen it, error SYN accepted after few retransmission

388 2009-05-05 17:57:50.507519000 10.234.1.225 10.234.1.116 TLSv1 Encrypted Alert
389 2009-05-05 17:57:50.507525000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [FIN, ACK] Seq=41886 Ack=47941 Win=64128 Len=0 TSV=127682130 TSER=4114
390 2009-05-05 17:57:50.508637000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [ACK] Seq=47941 Ack=41887 Win=8155 Len=0 TSV=4114 TSER=127682130
391 2009-05-05 17:57:50.508966000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [FIN, ACK] Seq=47941 Ack=41887 Win=8192 Len=0 TSV=4114 TSER=127682130
392 2009-05-05 17:57:50.509106000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [ACK] Seq=41887 Ack=47942 Win=64128 Len=0 TSV=127682130 TSER=4114
393 2009-05-05 17:57:50.538157000 10.234.1.116 10.234.1.225 TCP [TCP Port numbers reused] 6061 > sip-tls [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=4114 TSER=0
394 2009-05-05 17:57:50.538692000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=127682137 TSER=4114 WS=6
395 2009-05-05 17:57:50.538694000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [ACK] Seq=1 Ack=1 Win=8192 Len=0 TSV=4114 TSER=127682137
396 2009-05-05 17:57:50.625459000 10.234.1.116 10.234.1.225 SSL Client Hello

Trace which Show the Error

409 2009-05-05 17:57:57.728156000 10.234.1.225 10.234.1.116 TLSv1 Encrypted Alert
410 2009-05-05 17:57:57.728643000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [FIN, ACK] Seq=1640 Ack=335 Win=6912 Len=0 TSV=127683935 TSER=4129
411 2009-05-05 17:57:57.728645000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [ACK] Seq=335 Ack=1641 Win=8155 Len=0 TSV=4129 TSER=127683935
412 2009-05-05 17:57:57.729766000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [FIN, ACK] Seq=335 Ack=1641 Win=8192 Len=0 TSV=4129 TSER=127683935
413 2009-05-05 17:57:57.730839000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [ACK] Seq=1641 Ack=336 Win=6912 Len=0 TSV=127683935 TSER=4129
414 2009-05-05 17:59:35.138533000 10.234.1.116 10.234.1.225 TCP [TCP Port numbers reused] 6061 > sip-tls [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=75 TSER=0
415 2009-05-05 17:59:40.951988000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=86 TSER=0
416 2009-05-05 18:00:15.024207000 10.234.1.116 10.234.1.225 TCP [TCP Port numbers reused] 6061 > sip-tls [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=155 TSER=0
417 2009-05-05 18:00:15.024955000 10.234.1.225 10.234.1.116 TCP sip-tls > 6061 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=127718259 TSER=155 WS=6
418 2009-05-05 18:00:15.024958000 10.234.1.116 10.234.1.225 TCP 6061 > sip-tls [ACK] Seq=1 Ack=1 Win=8192 Len=0 TSV=155 TSER=127718259
419 2009-05-05 18:00:15.096919000 10.234.1.116 10.234.1.225 SSL Client Hello

Hi -

Short answer:
"Yes, TCP/IP works on Linux 2.3" (and all current versions of Linux too, for that matter)

Longer answer:
You've left out a lot of important information about the server, the platform, your application, and the topology.

But, in general:
1. The first SYN will be from a client trying to connect to a "well known port" (e.g. 6061)

2. The server will respond with an ACK and a SYN; the client will respond with another ACK, and the connection will be established (TCP/IP's "three-way handshake").

3. The connection will be on a *different* port (an "ephemeral port"): 6061 is just needed to *establish* the connection; it isn't monopolized for the entire duration of the connection.

4. When the connection is closed, the *ephemeral port* will be in a TIME_WAIT state for 2-3 minutes (and cannot be reused during that time).

5. But the server should generally be free to accept new connections on the "well known port" (e.g. 6061) all the while.

Bottom line:
TCP/IP itself is almost certainly OK. There's probably something wrong with the application (the "server" accepting connections on port 6061). Look there, first. Then look at the client (the guy who's initiating the connection). Next, look at any potential firewalls (hardware or software firewalls) between the two.

'Hope that helps .. PSM

Hi,

Thanks for the reply. The 6061 is the client port and server port is 5061(sip-tls). The server is not using the ephemeral port. It uses the same port 5061 but with a new soscket descriptor.
I don't see a new incoming TCP connection is coming to the application. It is basically getting TCP syn on the third time. How do we find out the kernel is dropping the packet?
The system is very much idle, which doesn't have much TCP connections also.

Thanks
jijo

Your client application is misbehaving. According to RFC 1323 -

B.2 Closing and Reopening a Connection

When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
state ties up the socket pair for 4 minutes (see Section 3.5 of
[Postel81]. Applications built upon TCP that close one connection
and open a new one (e.g., an FTP data transfer connection using
Stream mode) must choose a new socket pair each time.


Cheers

Pete