2

Suppose I have an TCP state transition diagram. And assume that the last ACK is lost. Then, B will think that A did not receive the FIN and will retransmit the FIN. From B point of view this is the same as if the FIN was lost, from A point of view this different since A now is in the

Case1 :TIME_WAIT

or

Case2 :CLOSED state.

case1: When A receives the new FIN from A if it is in the TIME_WAIT state it will send the ACK again(Understand this).

case2:If A is in the CLOSED state it will send a RESET(Don't Understand this), in either case B will be able to close its side of the connection.

A -----FIN-----> B
FIN_WAIT_1       CLOSE_WAIT
A <----ACK------ B
FIN_WAIT_2

(B can send more data here, this is half-close state)

A <----FIN------ B
TIME_WAIT        LAST_ACK
A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK
|
2MSL Timer
|
CLOSED
                 (timeout waiting for ACK)
A <----FIN------ B
A -----RST-----> B
                 CLOSED

My question is that why A send RST whenever it is in closed state?

2

See RFC 793:

Reset Generation

As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.

2

RST is sent by the side A doing the active close because it is the side which sends the last ACK. So if it receives FIN from the side B doing the passive close in a wrong state, it sends a RST packet which indicates other side that an error has occured because TCP RST is used in a scenario where TCP connections cannot recover from errors and the connection needs to reset forcibly.

Note: Active close is what happens when you explicitly call close system calls. Passive close when other end has done a close and the connection is half (or full) closed. When you explicitly close your side, it's an active close.

4
  • 2
    RST is sent by the side A doing the active close because it is the side which sends the last ACK. No. RST is sent because it received a segment out of sync. RST accurately terminates a potentially half-open connection on the far end as it's clearly not working correctly.
    – Zac67
    Sep 16 at 18:40
  • @zac Thats I mean you said in differently. Actually A send last ACK and wait and go to closed state. That means out of sync has started after closed.
    – Alok Maity
    Sep 16 at 18:51
  • 1
    A RST is generated because there is no longer a connection, so B is sending to a non-existent connection: "If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset."
    – Ron Maupin
    Sep 16 at 19:16
  • what is the value of "2MSL Timer"?
    – Effie
    Sep 17 at 13:21
1

In order to see why this is happening we need to consider these two things:

  1. TCP is stateful, in that both end-points of the connection are holding connection state. When the connection is closed, this state has to be deleted at some point. In TCP, connection state can be deleted when (immediately after) switching to CLOSE state.

  2. When TCP receives a segment, it has to be able to associate this segment to any existing connection. If there is no connection to associate the segment to, then TCP sends RST (see the answer of Zac67).

This is how these two facts apply to the situation.

A -----FIN-----> B
A <----ACK------ B

A <----FIN------ B
A -ACK ->   ???  B

A has sent an ACK. At this point the connection is closed by both A and B. So, the connection state is not needed anymore. However, since that last ACK can be lost, the standard specifies that A has to retain (portion of) connection state for 2 * MSL time interval. If the ACK is lost B will retransmit the FIN and A can resend it's ack. It also resets this 2*MSL timer.

According to the standard (RFC 793):

MSL - Maximum Segment Lifetime, the time a TCP segment can exist in the internetwork system. Arbitrarily defined to be 2 minutes.

I think some systems allow to configure the value of that timer. But, it should be large enough, so that retransmission(s) of the FIN arrives before the timer expires.

So, this can happen:

A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK

                 (timeout waiting for ACK) 
A <----FIN------ B
A -----ACK-----> B
|
restart 2MSL timer
|

And this should not have happened. If it does, it means that the timer was too short.

A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK
|
2MSL Timer
|
CLOSED
// timer value was too short(!)
                 (timeout waiting for ACK)
A <----FIN------ B
A -----RST-----> B
                 CLOSED

Let's see why is RST sent:

...
A -ACK ->   ???  B
TIME_WAIT     // A goes into TIME_WAIT state  
|
2MSL Timer
|            // The timer expires
CLOSED      // A deletes any connection state associated with this connection

So, if for some reason this gets to happen:

A <----FIN------ B

A does not have any connection state that is associated with this segment. It does not know what to do with it. Thus, according to specification it sends its RST.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.