1

When closing a TCP connection with a client, the client application will only visibly respond to the user when the connection is reset (an RST packet is sent). For now, I cannot modify the client application.

When researching this, the primary way to do so is by turning SO_LINGER on with a linger time of 0. However, I've noticed that socket closes as expected (e.g. not staying in TIME_WAIT for the system default time), but does not send a RST packet to the client.

I have tested this in WSL2 and Ubuntu (as its own VM, not part of WSL), and both have not sent the expected packet.

The server socket (the one that listen()s), has the SO_REUSEADDR option turned on, and the client socket (the one accept()ed) has the SO_LINGER option set appropriately, as well as TCP_NODELAY set on.

A thing to note is that the server creates a thread for each socket accepted. I'm unsure if this would impact the issue. I have also tried some solutions others have posted in other questions, but none have appeared to work.

I occasionally see in wireshark RSTs being sent after a couple executions of the server (for when I'm updating code and whatnot), but they are not sent immediately when they are closed or when the process is terminated.

Could any of the facts listed above be the cause of an RST packet not being sent, or is there a linux system option that needs to be changed to do so?

Thanks in advance. Let me know if more details are needed.

ninjaprawn
  • 11
  • 1
  • So the client does not react to the usual destroying of the socket with close(), which leads to a sequence with FIN etc.? You might want to take a look at this answer: https://stackoverflow.com/a/46264137. – Stephan Schlecht Jun 08 '20 at 11:49
  • @StephanSchlecht Tried the answer, no change in behavior was observed. Looking at wireshark, it seemed like a very similar packet sequence to that without that answer. Note that I did test with AND without `close()`ing the socket, with the same result both times. – ninjaprawn Jun 10 '20 at 06:15

0 Answers0