Recently I got a strange phenomenon that is server sends FIN/ACK at the same time without getting prior FIN from client(There was no FIN from client in my Wireshark dump at least.) As far as I know, normal TCP disconnection is 4 way hand shaking like FIN-ACK-FIN-ACK or 3 way like FIN - ACK/FIN - ACK, so if some one sends FIN/ACK there should be prior FIN to notify 'no more sending data & connection will be closed' from the counter part. I'm not sure this is just missing packet because I used port mirroring to grab the packets, or it is possible to happen normally. Any idea for this? No body experienced this before? asked 02 Mar '16, 00:56  Quatrefoil |
2 Answers:
There is no requirement for the client to send the first FIN. Either side (client or server) can send it whenever they want to signal "that's it, I have nothing more to say". 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. In the end you should see the connection terminate with 2 FINs and 2 ACKs belonging to the FINs. Sometimes you also see FIN - ACK - RST, where one side closes the connection with a rather harsh reset flag. If you have only one FIN flag (and no RST) your connection is technically still open. Be aware that FIN flags are often piggy-packed on data packets, which makes them easy to overlook. You should isolate your TCP connection first, and then search for FIN flagged packets within the connection to check if there are two FINs. answered 02 Mar '16, 03:55  Jasper ♦♦ |
The closing of TCP connection is never 3-way handshake but rather 2-way. Any of the device can initiate closing the session by sending the FIN packet, and it gets in to the FIN-WAIT1 state. Then it expect the other device to send the FIN afterwards for that it gets into the FIN-WAIT2 state. in this case connection can be resumed by the other devices if he is not wish to terminate the connection. When both devices are agreed to terminate the connection by sending their FIN and gets the ACK for them. The connection is terminated. That is the reason you are seeing four packets (that's not four-way handshake but two-way. For, ACK you are seeing along with FIN is the acknowledge for the last byte received. you can check the acknowledgement number as well to ensure that. answered 16 Sep '16, 16:14  sukhjit |
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. 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.
For your information, regarding piggy-packed FIN flags, I think it's enough to isolate with applying a filter such as "tcp.flags.fin==1", however I couldn't see any other FIN or RST besides one from Server. 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?
I'm little bit confused about representation of '[FIN, ACK]' in Wireshark info column, because I thought it was an answer for prior FIN from counter part. And I still have doubt that prior FIN from client was missed(not caught while grabbing the packets). Do you think this ACK just means ACK of other packet received previously, and nothing to do with prior FIN(something I doubt missed)?
ACK (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. the session has not been established yet).
Data 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. 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.
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. 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.
Presence of the FIN flag is counted, for the purpose of TCP sequence numbers, as an additional octet of payload. 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. Whether it sends, in the same packet, its own FIN flag or not, depends on the particular situation as Jasper has written above.