It seems to me that the repeated SYN+ACK from the server might be causing an issue as you correctly pointed out.
Would you mind enabling the debug messages by setting the macro
ipconfigHAS_DEBUG_PRINTF in FreeRTOSIPConfig.h present in your project? It would help us debug the issue faster.
Additionally, would you mind adding the following lines here:
if( pxSocket->u.xTCP.ucTCPState >= eESTABLISHED )
pxProtocolHeaders->xTCPHeader.ucTCPFlags &= ( ( uint8_t ) ~tcpTCP_FLAG_SYN );
and let us know whether you see any improvement?
A bit more explanation for the next person looking for this.
The FreeRTOS+TCP stack copies the last packet it received on a socket so that it can reuse the TCP packet header directly without much effort while sending the packet back to the peer. Generally, this works fine since the server doesn’t send a SYN-ACK packet again and the code goes on a merry path to sending an ACK and making the connection.
In this case, however, what is happening is that by the time when the server sends the SYN-ACK again, the FreeRTOS+TCP stack has marked the connection as established. The stack stores the SYN/ACK packet to be reused and discards it. Now, when it is time to send data (the HTTP packet), the TCP stack reuses the last packet it received (the one with SYN-ACK) to send data back to the server. And that is where the problem starts. The SYN flag is not reset and that makes the server unhappy.
The work around that I propose above removes the SYN flag unconditionally when the socket has gone beyond the
eESTABLISHED state - since the SYN flag should not be set anyways.
A point to note though: This is an extremely weird corner case. It doesn’t happen often. We shall create a PR in the repository to fix this issue.