Ask Your Question

(TCP) Server responds FIN,ACK before getting ACK from Client

asked 2021-11-28 20:34:27 +0000

Marti gravatar image

The Server responds to the Client and doesn't wait for the Client to respond with an ACK confirming that it has received everything before closing the connection. Am I just getting this wrong and the protocol is working just fine or is this not supposed to happen? I would add an image but the webpage won't let me.

edit retag flag offensive close merge delete


Can you share a file capture?

BigFatCat gravatar imageBigFatCat ( 2021-11-28 23:14:08 +0000 )edit

Is that FIN after the SYN packet? Or do you get SYNC?ACK first from the server? A simple flow can be put in plain text easily enough.

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2021-11-29 08:24:29 +0000 )edit

The message sequence is what you'd normally expect, SYN from C, SYN,ACK from S... and then at the end a FIN,ACK from the S. Here's a capture:

Marti gravatar imageMarti ( 2021-11-29 08:34:40 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-11-29 12:57:27 +0000

BigFatCat gravatar image

frames 6-7 192.168.116 send 6 packets. It looks the MSS is 1448 frame 8 sends a PUSH because has not acknowledge the packets that were sent. frame 9 terminates the session. frames 10-13 sends ACKS. I can't see the ACKs, but my guess they are acknowledgements for the frames 6-8.

I don't know if it's expected behavior to end the session. It is impossible to time stamp when sent the packets because of the TCP offloading. I would compare this capture to a good session.

edit flag offensive delete link more


I'm not sure if should send all this ACK and the ending PSH,ACK not waiting for to give an ACK, but I think it could be correct What I think is not ok is that terminates the connection not waiting for all the ACK from

I don't understand what you mean with the capture to a good session.

Marti gravatar imageMarti ( 2021-11-29 13:15:35 +0000 )edit

The session is established with a 3-way handshake. Any time afterwards, either peer can send a FIN or RST to end the session. If the application is written correctly, it is the application that tells TCP that it is no longer necessary. The session will then be terminated by either a FIN or RST.

Why the FIN was sent is not clear. Did the application end the session or is there a problem at the TCP layer?

A comparison to a good session. Can packets be captured from a working client? It will be useful to see what the protocol looks like when it works.

BigFatCat gravatar imageBigFatCat ( 2021-11-29 23:33:40 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-11-28 20:34:27 +0000

Seen: 168 times

Last updated: Nov 29 '21