This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

[RST, ACK] immediately after FIN flag

0

Hi,

I'm trying to figure out a problem where I'm getting multiple socket exceptions on client machines on the network. Clients always connect to the server, send some data and the server always sends some data back to every client. I've run a prolonged capture and I'm seeing that when the problem occurs, the server seems to be sending the data back to the client, but almost immediately after that the server sends an RST+ACK packet, as shown below:

No.     Time        Source     SRC_Port Destination   DST_Port        Protocol Length Info

3634    0.000   203.38.235.197  62379   10.0.8.29   610 TCP         62379→610 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=682375632 TSecr=0


3635    0.000   10.0.8.29   610 203.38.235.197  62379   TCP         610→62379 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1 TSval=292263667 TSecr=682375632


3636    0.000   203.38.235.197  62379   10.0.8.29   610 TCP         62379→610 [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSval=682375632 TSecr=292263667


3637    0.000   203.38.235.197  62379   10.0.8.29   610 TCP         62379→610 [PSH, ACK] Seq=1 Ack=1 Win=14600 Len=341 TSval=682375632 TSecr=292263667


3638    0.000   203.38.235.197  62379   10.0.8.29   610 TCP         62379→610 [ACK] Seq=342 Ack=1 Win=14600 Len=1448 TSval=682375632 TSecr=292263667


3639    0.000   10.0.8.29   610 203.38.235.197  62379   TCP         610→62379 [ACK] Seq=1 Ack=1790 Win=65160 Len=0 TSval=292263667 TSecr=682375632


3640    0.000   10.0.8.29   610 203.38.235.197  62379   TCP         610→62379 [FIN, ACK] Seq=1 Ack=1790 Win=65160 Len=0 TSval=292263667 TSecr=682375632


3641    0.000   10.0.8.29   610 203.38.235.197  62379   TCP         610→62379 [RST, ACK] Seq=2 Ack=1790 Win=0 Len=0


3642    0.000   203.38.235.197  62379   10.0.8.29   610 TCP         62379→610 [PSH, ACK] Seq=1790 Ack=1 Win=14600 Len=5 TSval=682375632 TSecr=292263667


3643    0.000   10.0.8.29   610 203.38.235.197  62379   TCP         610→62379 [RST] Seq=1 Win=0 Len=0`

Any suggestion will be very much helpful for me to resolve the issue.

Regards, Nikhil Keshrwani

asked 24 Jan ‘16, 18:47

Nikhil174's gravatar image

Nikhil174
6●1●1●2
accept rate: 0%

edited 25 Jan ‘16, 00:49

sindy's gravatar image

sindy
6.0k●4●8●51

Could you share us a trace file? Without a tracefile it is hard to give you some reliable statements.
But the behaviour you are asking about, could be some kind of “half-duplex close”. Which is used by some implementation as a workaround for the time_wait behaviour.
of course in your case the RST can be an indication of a failure, too.
But without the capture it hard to tell, as I already said.
Have you ever compared this session with a session where everything went fine?

(25 Jan ‘16, 03:31) Christian_R

https://drive.google.com/file/d/0Bwpm-1j243baM3pkS3hmTnVxZXc/view?usp=sharing

Thanks for the reply here is the file you can download

Regards, Nikhil

(25 Jan ‘16, 07:07) Nikhil174

Easily said: I guess the problem is application related. Because the server (10.0.8.29) is sending a FIN packet.

Does the logfiles(Server OS or Server Application) give you some hints to identify the cause of the FIN´s?

Furthermore I can´t exactly say (delta time is very low + internal server behaviour) if the FIN is send immediately after the end of the Three-Way-Handshake (Stream Indx 365) or if the first client packet is causing the FIN (for example like Stream Indx 1).

But I guess relative reliable, that the RST is only a follow up or normal.

(25 Jan ‘16, 12:57) Christian_R

One Answer:

0

To me it looks like two issues at the same time

  • one is that the server does not like something about the sending client or about the data contents and so it sends a FIN before the client has managed to say all it wanted to say. This would be supported by the fact that I can never see any answer of the server, the session always contains only data sent by the client. So repeating @Christian_R's question - do you have also any successful sessions or all look like this?

  • another one is that in many cases, the server sends the RST just about 40-50 microseconds after the FIN it has sent itself, i.e. it most likely does not send it as a reaction to reception of another packet from the client after it has sent the FIN (assuming the capture is taken at the server itself). So I would assume that if it is not a plain bug, it may be the server's attempt to release its session descriptors for eventual new session coming from the same port of the same client, as @Christian_R has suggested.

answered 25 Jan '16, 07:40

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%