First time here? Check out the FAQ!

Ask Your Question
0

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

asked Nov 28 '1

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.

Preview: (hide)

Comments

Can you share a file capture?

BigFatCat gravatar imageBigFatCat ( Nov 28 '1 )

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 ( Nov 29 '1 )

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 gravatar imageMarti ( Nov 29 '1 )

1 Answer

Sort by » oldest newest most voted
0

answered Nov 29 '1

BigFatCat gravatar image

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.

Preview: (hide)
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 gravatar imageMarti ( Nov 29 '1 )

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 ( Nov 29 '1 )

Your Answer

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

Add Answer

Question Tools

2 followers

Stats

Asked: Nov 28 '1

Seen: 953 times

Last updated: Nov 29 '21