FIN_WAIT state in TCP networking

FIN_WAIT_2 seems to occur when the server has an active connection with a client and wants to shut down the TCP connection (probably in response to a normal application layer "exit"). The server sends the client a packet with a "FIN" bit set. At this point, the server is in FIN_WAIT_1 state. The client gets the FIN packet and goes into CLOSE_WAIT state, and sends an acknowledgment packet back to the server. When the server gets that packet, it goes into FIN_WAIT_2 state. From the server's perspective, the connection is now closed, and the server can't send any more data. However, under the TCP protocol, the client needs to shut down also by sending a FIN packet, which the server TCP implementation should ACK. The server should close after a period of time defined by the Maximum Segment Lifetime (MSL).

The following diagram is taken from RFC 793 (defining the TCP protocol):

     TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --< CLOSED

  6.  (2 MSL)

Some clients have faulty TCP implementations, and leave the server hanging in FIN_WAIT_2 state. In particular, this can cause problems with Indiana University's Sirsi Symphony (formerly Unicorn) system.

This is document ajmi in the Knowledge Base.
Last modified on 2019-01-18 13:09:03.