Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Reason behind TCP RST from Client

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.

I can post the filtered pcap file - just let me know how to do so.

Reason behind TCP RST from Client

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.

I can post the filtered pcap file - just let me know how to do so.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

Reason behind TCP RST from Client

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 client, and packet 51 which is from the same client but almost 1 second later, with SEQ# that is lower than packet 50. Wireshark marks it TCP Spurious retransmission but it looks like a TCP Keepalive.

I am also puzzled why it took so long from packet 50 to packet 52 for the server to send a DUP ACK (ie. about 950ms).

Reason behind TCP RST from Client

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

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

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

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

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

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

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

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

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 client, and packet 51 which is from the same client but almost 1 second later, with SEQ# that is lower than packet 50. Wireshark marks it TCP Spurious retransmission but it looks like a TCP Keepalive.

I am also puzzled why it took so long from packet 50 to packet 52 for the server to send a DUP ACK (ie. about 950ms).