So when the TCP stack receives a packet with FIN flag set and with payload whose last octet's sequence number is N, it sends an ACK for N+1. Presence of the FIN flag is counted, for the purpose of TCP sequence numbers, as an additional octet of payload. So if a party has not received any payload during the time it has itself sent three packets, the ACK sequence number in all these three packets is the same, but it is always there. Instead, while sending your own packets, you use the ACK sequence number to inform the remote party about the sequence number of the last payload octet you have received from them without a gap in the data. One of the reasons is that doing so would terribly slow down the transfers as the network path round trip would elapse between any two messages sent. In the end you should see the connection terminate. It also doesn't mean that the other side has to signal the same - it can continue to send data as much as it likes. Either side (client or server) can send it whenever they want to signal 'that's it, I have nothing more to say'. the session has not been established yet).ĭata reception acknowledging in TCP does not work packet by packet (or message by message) like in older, mostly point-to-point, protocols where you would not send the next message until you've received an ACK for the last sent one. There is no requirement for the client to send the first FIN. Do you think this ACK just means ACK of other packet received previously, and nothing to do with prior FIN(something I doubt missed)?ĪCK (the flag and the corresponding sequence number) is present in almost all TCP packets, with two exceptions: the client's SYN packet (as there is nothing to ACK yet), and the client's RST packet in case that the server has not responded to the client's SYN (i.e. Mathematically and programmatically we deduce the minimum operating point of operation of an IDS and generate the receiver operating characteristic curve of the. And I still have doubt that prior FIN from client was missed(not caught while grabbing the packets). I'm little bit confused about representation of '' in Wireshark info column, because I thought it was an answer for prior FIN from counter part. In this case, does it mean the server tried to terminate connection by sending FIN but the client didn't send corresponding FIN or RST yet? As you mentioned I should see two FINs or FIN-RST at the end of the packets if the connection terminated firmly, but I couldn't so I guess there's something wrong in implementation.įor your information, regarding piggy-packed FIN flags, I think it's enough to isolate with applying a filter such as "=1", however I couldn't see any other FIN or RST besides one from Server. Thank you for answer my question Jasper, I wasn't saying that there are any rule or order to initiate FIN first, yes, either side can send FIN whenever they want to terminate the connection.