Ask Your Question
0

(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

Comments

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: https://imgur.com/a/9BmqW5y

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

1 Answer

Sort by ยป oldest newest most voted
0

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 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.

edit flag offensive delete link more

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 ( 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

2 followers

Stats

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

Seen: 168 times

Last updated: Nov 29 '21