Socket is stuck in FIN_WAIT (0x18) state.

Question

I have a problem, my HTTP server freezes after a few days of operation. I found that this is due to the fact that the state of the socket is not completely closed (FIN_WAIT (= 0x18)). I work with W5500 on interrupts, so I can not once again interrogate and see the state of FIN_WAIT, to send comand CLOSED maybe I skip interruption of disconnection on this so it all happens. I can not understand why the socket does not go into the CLOSED state? what external event or internal could trigger such a change? There are also some questions about the operation of the TCP server In the LISTEN state, should a timeout and socket re-open occur?

Eugeny · Answer

I guess that your server wants to close the socket after communication is over at its side, sends FIN packet to “properly” disconnect, and never receives FIN/ACK back from the client. The solution is simple and ugly. You perform DISCON command, wait until it completes, and then perform CLOSE command - and the socket is freed. If remote client will send FIN/ACK back, or will try to talk to the socket, it will get RST packet - this is not a problem because your server is finished with the communicaton and this is in compliance to the TCP proto (if you care about a kind of broken communication process).

Maksim · Answer

Yes, rather you are right, I tested the server through a mobile phone, possibly due to a slow connection, the w5500 did not receive a response signal FIN. How to determine that a disconnect command has been completed? As I wrote, I work through interrupts, and read the register Sn_IR “Sn_IR (DISCON) Interrupt Thisis issued when FIN or FIN / ACK packet is received from a peer” I understand w5500 set this flag after the client answers FIN?

Maksim · Answer

For such an event (client not to send the FIN packet) must not be called TIMEOUT? RTR During the time configured by RTR, W5500 waits forthe peer response to the packet that is transmitted by Sn_CR(CONNECT, DISCON, CLOSE, SEND, SEND_MAC, SEND_KEEP command). If the peer does not respondwithin the RTR time, W5500 retransmits the packet or issues timeout

Maksim · Answer

Oh, that’s great, since it fits my system well. This happens, rarely enough, so I’m not very scared that the server will free up a bit later, the main thing is that it would free up and not freeze. The only strange thing is that I have this processing, but for some reason it doesn’t help = ( RTR = 200 and RCR = 3 so that it should be released quickly enough. How I can this situation be emulated? Can I send SYN,FIN packages manually?

Maksim · Answer

I started to see what was going wrong first caught retransmissions. 192.168.0.114 is wiznet, I fill the entire packet into the socket and give the send command why does it send the packet 2 (3 times) splits it into 3 segments? pack (5,6,7) and why send pack 8 ? dump1397×171 19.3 KB Dump_CGI_GetVar.pcapng.zip (5.2 КБ) This is a json request dump 3 times tcp out -of order norms

Eugeny · Answer

There seem to be generic logic mistake in how code behaves. Spurious retransmission @24 must not happen, and I am afraid it is W5500 driver instructs to send the data again for some reason.

Maksim · Answer

No, no, everything is correct with the order, the heading is sent first, then the body. I don’t know why Wireshark in the info column displays like this I open pack header (№5 196 byte): Header1440×824 68.1 KB In this case, wiznet was connected to the computer via cable directly without switches and routers.

Eugeny · Answer

Maksim: everything is correct with the order Wireshark shows: client sends request for /GetPageVar.CGI server sends ACK server sends header HTTP/1.1 200 OK and immediately performs DISCON and only after DISCON sends the contents of 830 bytes.

Maksim · Answer

You about pack 5-7 ? Order1342×800 77.3 KB