First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

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

  • retag add tags

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.

Marti's avatar
1
Marti
asked 2021-11-28 20:34:27 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Can you share a file capture?

BigFatCat's avatar BigFatCat (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's avatar hugo.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: https://imgur.com/a/9BmqW5y

Marti's avatar Marti (2021-11-29 08:34:40 +0000) edit
add a comment see more comments

1 Answer

0

frames 6-7 192.168.116 send 6 packets. It looks the MSS is 1448 frame 8 192.168.1.116 sends a PUSH because 192.168.1.111 has not acknowledge the packets that were sent. frame 9 192.168.1.116 terminates the session. frames 10-13 192.168.1.111 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 192.168.1.116 sent the packets because of the TCP offloading. I would compare this capture to a good session.

BigFatCat's avatar
31
BigFatCat
answered 2021-11-29 12:57:27 +0000
edit flag offensive 0 remove flag delete link

Comments

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

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

Marti's avatar Marti (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's avatar BigFatCat (2021-11-29 23:33:40 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer