0

Does anyone have an idea why connect() would continue before the three-way handshake is finalized?

According to what I captured by tcpdump the client sends a [PSH,ACK] with data before sending the last ACK of the three-way handshake.

NO_DELAY option is used.

Connect code :

do {

    r1 = connect(socketfd, addr->ai_addr, addr->ai_addrlen);

  } while (r1 < 0 && errno == EINTR);

tcpdump sequence

FilipPudak
  • 1
  • Sending data with the final ACK is allowed. – Ron Maupin May 03 '21 at 13:54
  • Hi @RonMaupin, yes but check the tcpdump sequence. Why would the server send an RST in that case? And why does the client send another ACK immediately following the [PSH,ACK]? Receipt of any TCP segment from any device with which the device receiving the segment does not currently have a connection (other than a SYN requesting a new connection.) -> http://www.tcpipguide.com/free/t_TCPConnectionManagementandProblemHandlingtheConnec.htm – FilipPudak May 03 '21 at 14:02
  • There is a specific section in [RFC 793](https://tools.ietf.org/html/rfc793) called Reset Generation that explains the circumstances for a host to send a RST. – Ron Maupin May 03 '21 at 14:07
  • Thanks for the link to the RFC @RonMaupin. Could you comment on the sequence I attached above though? The thing that sticks out for me is the [PSH, ACK] and the ACK sent from the client right after it. Is this a valid sequence? It seems that could lead to generating the RST? – FilipPudak May 03 '21 at 14:13
  • @FilipPudak: The order of the packets is for sure strange. It first sends 16 bytes with a sequence number of 1 and the next packet is a an empty ACK, but with a sequence number of 1 too. It should have been a sequence number of 16 if this is really the next packet. But given that the two packets are really fast after each other it might just be that the order is switched. This can happen on normal wire but is unusual with loopback interface. In any case, it should not cause a RST. If this is really reproducible provide the necessary details and minimal code and ask at stackoverflow.com. – Steffen Ullrich May 03 '21 at 18:11
  • @SteffenUllrich, thanks for the answer. I agree with your analysis. The reproducibility of this is very low(once case in 2 weeks of continuous testing), but you are right, maybe this sort of question is more fitting for stackoverflow. – FilipPudak May 04 '21 at 09:41

0 Answers0