Seeing an issues where a remote host seems to be sending an ACK for a packet it never received. What is really strange is that the ACK# it sends is extremly high and way out of line with normal sequence#/ACK flow. This happens repeatedly on this one host.
2015-09-17 09:21:21 |TCP: 55206→51583 [PSH, ACK] Seq=10689 Ack=797 Win=7936 Len=8 TSval=3510183220 TSecr=64598928 **(Source server sends and an 8 byte packet of data) (Sequence# 10689 + 8 bytes = Ack# 10697 seen in the next packet)**
2015-09-17 09:21:21 |TCP: 51583→55206 [ACK] Seq=797 Ack=10697 Win=39680 Len=0 (Destination Server ACKs the packet)
2015-09-17 09:21:24 |TCP: [TCP ACKed unseen segment] 51583→55206 [PSH, ACK] Seq=797 Ack=1073751598 Win=34048 Len=62 (Approx 3 seconds later Destination server sends an ACK for a packet it never received. Notice the extremely high Ack#)
2015-09-17 09:21:24|TCP: 55206→51583 [RST] Seq=1073751598 Win=0 Len=0 (Source server resets the connection. I assume it is because of the previous packet)
Just wondering if anyone has seen this type of behavior before?
asked 17 Sep ‘15, 10:02
Racer5
6●1●1●2
accept rate: 0%
edited 17 Sep ‘15, 12:38
grahamb ♦
19.8k●3●30●206
Interestingly enough, 1073751598 is 0x4000262e. and 0x262e is 9774
I don’t know what’s going on, but maybe the fact that Wireshark normally shows relative sequence numbers (i.e., offset from the actual sequence number seen in the first captured packet for the TCP connection) is causing some confusion.
So: the first thing I would do is to go to the Wireshark TCP protocol preferences and disable relative sequence numbers and then look again at the capture.
Yes I would turn off the relative sequence numbers, too. Are there any Loadbalancers or Firewalls between the server and the client?
would it be possible to post a sample capture file somewhere?
BTW: What is your Wireshark version?