connect() succeeds, but 3-way handshake is RST by server

[Kris]

Hello there.
I am experiencing a strange problem with TCP on a windows 2008 server. The
situation is as follows: I am opening a lot of connections to a socket that
is in the listen() mode. Now, some connections succeed, but some appear to
succed, but immediately fail on the initial send.

A wireshark trace shows the following:
client -> server SYN
server -> client SYN,ACK
client -> server ACK,
server -> client RST

In other words, for the final ack of the 3 way handshake, the client
receives a RST. At this point, the client's connect() call has returned
successfully but the connection has been reset already.

On the server side, accept() didn't return anything (a socket or an error)
for this connection attempt. This is not a case of the server calling
closesocket() after a successfule accept()

I've trawled the net and I have found no information about why the server
would do this. I thought that this might be some kind of SYN flooding
response, but that sounds unlikely.

The actual trace for a failed attempt is here. Note a previous syn 3s
before that goes unanswered. This is a retry.:
No. Time Source Destination Protocol Info
339 5.863214 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [SYN] Seq=0 Win=8192 Len=0 MSS=1460
552 8.853914 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [SYN] Seq=0 Win=8192 Len=0 MSS=1460
562 8.853975 10.1.4.164 10.1.4.86 TCP
mvs-capacity > 62876 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460
572 8.854131 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [ACK] Seq=1 Ack=1 Win=64240 Len=0
575 8.854164 10.1.4.164 10.1.4.86 TCP
mvs-capacity > 62876 [RST] Seq=1 Win=0 Len=0


Any ideas?

[m]

Look in MSDN for AcceptEx(). IIRC in the notes there is a discussion of the
stack behaviour wrt embryonic connections.

Post by Kris
Hello there.
I am experiencing a strange problem with TCP on a windows 2008 server.
The
situation is as follows: I am opening a lot of connections to a socket that
is in the listen() mode. Now, some connections succeed, but some appear to
succed, but immediately fail on the initial send.
client -> server SYN
server -> client SYN,ACK
client -> server ACK,
server -> client RST
In other words, for the final ack of the 3 way handshake, the client
receives a RST. At this point, the client's connect() call has returned
successfully but the connection has been reset already.
On the server side, accept() didn't return anything (a socket or an error)
for this connection attempt. This is not a case of the server calling
closesocket() after a successfule accept()
I've trawled the net and I have found no information about why the server
would do this. I thought that this might be some kind of SYN flooding
response, but that sounds unlikely.
The actual trace for a failed attempt is here. Note a previous syn 3s
No. Time Source Destination Protocol Info
339 5.863214 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [SYN] Seq=0 Win=8192 Len=0 MSS=1460
552 8.853914 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [SYN] Seq=0 Win=8192 Len=0 MSS=1460
562 8.853975 10.1.4.164 10.1.4.86 TCP
mvs-capacity > 62876 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460
572 8.854131 10.1.4.86 10.1.4.164 TCP
62876 > mvs-capacity [ACK] Seq=1 Ack=1 Win=64240 Len=0
575 8.854164 10.1.4.164 10.1.4.86 TCP
mvs-capacity > 62876 [RST] Seq=1 Win=0 Len=0
Any ideas?

[Kris]

Post by m
Look in MSDN for AcceptEx(). IIRC in the notes there is a discussion of the
stack behaviour wrt embryonic connections.

I found no such information. I am actually using AcceptEx() with
IOCompletion. But I receive no completion requests for connections that are
accepted and then rejected like this.
Is this normal behaviour? I have never found any suggestion that one had to
"test" a connected connection with a send() to be sure that it was "really"
connected.

Any information would be appreaicated.

[m]

Apologies: look at Listen() in MSDN + backlog in KB.

In my experience, this is definitely not correct behaviour, but is often
observed in the presence of certain firewalls. This is also a valid
condition in TCP when a network disruption occurs immediately after connect
and your application should handle it,

Post by Kris

Post by m
Look in MSDN for AcceptEx(). IIRC in the notes there is a discussion of the
stack behaviour wrt embryonic connections.

I found no such information. I am actually using AcceptEx() with
IOCompletion. But I receive no completion requests for connections that are
accepted and then rejected like this.
Is this normal behaviour? I have never found any suggestion that one had to
"test" a connected connection with a send() to be sure that it was "really"
connected.
Any information would be appreaicated.