Bug report: TCP socket send hangs if remote endpoint's receive window is small, when sending a large packet

The setup is that there is a remote server that has a small TCP receive window (in this case 100 bytes) and a local nRF9160 device trying to send 4000 bytes to that server.

Code for nRF9160:

Server code below. Works on a Windows computer, compile using gcc on MSYS2 or Cygwin (not mingw). Linux does not work since it cannot use such small TCP receive windows.

Output on nRF9160:

It permanently hangs in the send call. Wireshark on the server shows that only the TCP three-way handshake is performed and not a single byte of data is sent. The server then closes the connection (sends FIN) after a while and the nRF9160 modem successfully ACKs this packet. Finally, the server force-closes the connection using a RST packet. Not even at this point does the send call return. Please ignore the retransmission and dup ack in the image.

The expected outcome is that the send function should accept between 1 and 4000 bytes, put that amount of bytes in its send buffer and return the number of bytes processed, for example 100 since the receiver's receive window is 100 (alternatively, for a socket in blocking mode, it is ok to block and return first when all bytes have actually been sent). Also when the remote endpoint sends RST, I expect a blocking send call to return (with an error). Even if I put MSG_DONTWAIT in the flags to enable non-blocking mode, the function hangs in the exact same way.

If I try to send a smaller buffer, like 1000 bytes instead, then the function does not hang anymore. If I try to send the same 4000 bytes big buffer, but increase the receive window size on the remote server, everything also works fine.

Obviously there is some bug in the implementation that happens with small receive windows when the user tries to send a large packet.

nRF Connect SDK version: 2.3.0.

Modem firmware version: 1.3.4.

Mobile operator: Telenor SE.