1

I've encountered an force termination by a host, even after a successful (at least it seems to be successful; correct me if I'm wrong) FIN ACK close of connection. Packet trace at the moment is attached below. I've left the last digit of hosts unmasked to identify them separately.

My analysis is this: Despite the out of order packet, the connection termination handshake went well, but after that, one party calls an RST.

Window update, FIN termination went well right? How an RST is possible if connection is closed by the FIN already?

packet trace

3
  • Out of order packet delivery happens all the time, and TCP is made to handle that, unlike UDP. Unfortunately, questions about programming are off-topic here. You can ask programming questions on Stack Overflow, but they will want more information. The RST is generated by one side to force the connection closed. The reason that happens is up to the host that sent the RST. It looks like you may have had a closed connection that forced the RST when one side got a segment for a closed connection. You blanked the source and destination addresses, so it is hard to say.
    – Ron Maupin
    Aug 16 '17 at 14:36
  • I will assume that you're connecting over the Internet. In that case, out of order packets are common. It's up to the application to decide what to do about that. And, sadly, application questions are off-topic here.
    – Ron Trunk
    Aug 16 '17 at 14:40
  • @RonMaupin ,RonTrunk Please disregard the application context (First time posting here, didn't know applications are not welcome :) ) I've left the last digits visible to identify the two hosts. What i want to know is here the FIN process completes successfully despite the out of order packet right? And the window update doesn't seem to be gone wrong too right? Thanks in advance - i'll edit the question Aug 16 '17 at 17:48
2

The RST is in response to receiving something on a connection that no longer exists. The connection was closed by FIN, and it was acknowledged, so the connection no longer exists, and then something was received on the closed connection, so a RST was sent. This is actually covered in RFC 793, Transmission Control Protocol:

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.

There are three groups of states:

  1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the CLOSED state.

  2. If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.

    If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the same state.

  3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.

1
  • I don't understand. 218 sent his FIN, then 5 acked it and in segment 5419 sent his FIN. In 5421, 218 acks the last FIN, and 2 microseconds afterwards sends a RST. It's either we're missing packets. or seeing them mis-ordered here. Or I don't understand what's happening...
    – Jong
    Sep 19 '19 at 8:26

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.