Reason behind TCP RST from Client

asked 2019-06-13 16:00:10 +0000

batteryworm gravatar image

updated 2019-06-13 16:52:43 +0000

grahamb gravatar image

I need someone to help me interpret what is going on with the tcpdump I have - this is taken on the server end. And why the client sends two RST packet out of the blue.

I have a client which has TCP connection was established to a server for some 9 hr plus and was able to remain connected without any issues. Towards the end of the 9 hrs, there is little data and I can see the client sends keepalive packets now and then at intervals of about 1 second. Then suddently the following happens and the client sends two RST packet as follows:

  1. The server sends some data (100 bytes) to the client,
  2. The client sends back an ACK but with its own (client's) SEQ # about 138 bytes ahead of what the server expected so Wireshark marks this as previous segment not captured.
  3. About 1 second later the client sends another ACK packet this time round it looks like a Keepalive (because the SEQ # is one less than what server expects).
  4. The server respond to this Keepalive packet (Wireshark marks as DUP ACK)
  5. At this point in time, the client sends a RST, ACK with the SEQ # of 2. above (i.e 138 bytes ahead of what server is expecting)
  6. The server sends another ACK packet which is the same as 4. above.
  7. The client sends another RST packet (without ACK) this time with the SEQ # 1 bytes more than that in 3. above.

The above 7 packets looks like this in text export.

No. Delta time  Source       Destination   Proto SEQ#       Len Next SEQ#  ACK#      Info

49  0.907097000 10.29.51.64  10.218.38.10  TCP   432014999  154 432015099  567110547 23024 → 56564 [PSH, ACK] Seq=432014999 Ack=567110547 Win=128 Len=100

50  0.061696000 10.218.38.10 10.29.51.64   TCP   567110685  60  567110685  432015099 [TCP Previous segment not captured] 56564 → 23024 [ACK] Seq=567110685 Ack=432015099 Win=513 Len=0

51  0.951149000 10.218.38.10 10.29.51.64   TCP   567110546  60  567110547  432015099 [TCP Spurious Retransmission] 56564 → 23024 [ACK] Seq=567110546 Ack=432015099 Win=513 Len=1

52  0.000003000 10.29.51.64  10.218.38.10  TCP   432015099  54  432015099  567110547 [TCP Dup ACK 40#1] 23024 → 56564 [ACK] Seq=432015099 Ack=567110547 Win=128 Len=0

53  0.040958000 10.218.38.10 10.29.51.64   TCP   567110685  54  567110685  432015099 56564 → 23024 [RST, ACK] Seq=567110685 Ack=432015099 Win=0 Len=0

54  0.000003000 10.29.51.64  10.218.38.10  TCP   432015099  54  432015099  567110547 [TCP Dup ACK 40#2] 23024 → 56564 [ACK] Seq=432015099 Ack=567110547 Win=128 Len=0

55  0.002142000 10.218.38.10 10.29.51.64   TCP   567110547  54  567110547  567110547 56564 → 23024 [RST] Seq=567110547 Win=0 Len=0

Note: I am puzzled by the packet 50 which signifies that there is a missing or dropped packet just before this packet from the ... (more)

edit retag flag offensive close merge delete

Comments

To me this looks like packet loss. 138 byte from client to server are lost, obviously the server cannot ACK them, missing ACK is not tolerated by the client ==> resets the connection. Maybe even some of the ACKs from the server are being dropped on their was to the client. Would it be possible to see a pcap file from both sides of the same occurrence to confirm this?

SomeRando gravatar imageSomeRando ( 2019-06-17 19:43:23 +0000 )edit

Thanks for your comments. We have been trying to get the pcap from the other side but no response so far. Will update if any new development.

batteryworm gravatar imagebatteryworm ( 2019-06-29 17:35:50 +0000 )edit