Home/ Questions/Q 6626055
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T21:50:54+00:00

I have run Wireshark on the server’s computer and I have such a strange

  • 0

I have run Wireshark on the server’s computer and I have such a strange transmission:

Client (X: src port 65509) connects to my server (Y: dst port 9999).

1) There is normal TCP handshake

15:47:41.921228 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [SYN] Seq=0 Win=8688 Len=0 MSS=1460 WS=0 SACK_PERM=1 TSV=66344090 TSER=0
15:47:41.921308 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   distinct > 65509 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1 TSV=69754693 TSER=66344090
15:47:42.176823 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [ACK] Seq=1 Ack=1 Win=8688 Len=0 TSV=66344350 TSER=69754693

2) Server sends an encryption key to the client and client ACKs receiving it:

15:47:42.180755 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   distinct > 65509 [PSH, ACK] Seq=1 Ack=1 Win=65160 Len=24 TSV=69754719 TSER=66344350
15:47:42.452606 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [ACK] Seq=1 Ack=25 Win=8664 Len=0 TSV=66344630 TSER=69754719

3) Suddenly panel Resets the connection for some reason

15:47:42.948618 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [RST] Seq=28 Win=0 Len=0

4) But the strange thing to me goes here. Server sends TCP Dup ACK. What can be the reason for that? I thought this message can be sent only after retransmission or sth. I’ve never seen it to be sent after RST.

15:47:42.948654 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   [TCP Dup ACK 5856#1] distinct > 65509 [ACK] Seq=25 Ack=1 Win=65160 Len=0 TSV=69754796 TSER=66344630**

5) Client sends RST again.

15:47:43.227269 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [RST] Seq=1 Win=0 Len=0

Thanks for any suggestions.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The Dup-ACK from server in step(4) is caused by the Seq 28 in step(3):

          65509 > distinct [RST] Seq=28 Win=0 Len=0

    Because server is expecting Seq#25 but received #28. This happens when seq 25~27 is lost in the network. The Dup-ACK notifies the client to re-transmit lost data before the RST; however, in step(5), we see the client, in response to server’s dup-ack, reset again. So client data #25~27 never reached the server and is gone.

    You can verify this by doing packet capture on both server and client.

    For details, read some TCP re-transmission document.

    • 0