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

PSH ACK After ACK Acknowledging same frame but time delta is huge

hi all, I am debugging intermittent issues between a client and server application (this application is using IE to load images it used to be on windows XP after PC is upgraded to windows 7 IE 8 users complain complans that intermittently image loads slowly.

i can only observe that in the pcap file of the client PC during the issue PSH ACK after ACK with same ACK number.

Client -> Server [SYN] Server-> Client [SYN, ACK] Client -> Server [ACK] Client -> Server [PSH,ACK] Server -> Client [ACK] Server-> Client [PSH, ACK] Client -> Server [ACK] //ack 1233 Client -> Server [PSH,ACK] //this push ack is acknowledging the same number as previous frame ack 1233 but there is a delay of 19 sec of delay from previous frame which is the cause of the delay.

i am thinking the delay is the client is sending the request slowly. like to check if anyone has seen this issue before and possible causes. thanks in advance

Client: 10.205.10.58 Server: 10.203.12.144 alt text

ack psh after packet-capture

asked 17 Aug '15, 05:50

pavil1985
6●1●2●3
accept rate: 0%

edited 17 Aug '15, 08:15

One Answer:

The first Frame is an normal ACK. And the second marked frame contains new data. The GAP is application related. But I can´t read the times clearly out of the screenshots. It would be better if you could provide a trace.

answered 17 Aug '15, 12:03

Christian_R
1.8k●2●6●25
accept rate: 16%

edited 17 Aug '15, 12:03

hi Christian_R,

Hope this is a better view, apologies for the bad screenshot.

Time Source Destination Info

15:33.3 10.205.10.58 10.203.12.144 58221 > irdmi [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 15:33.4 10.203.12.144 10.205.10.58 irdmi > 58221 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1400 SACK_PERM=1 15:33.4 10.205.10.58 10.203.12.144 58221 > irdmi [ACK] Seq=1 Ack=1 Win=64400 Len=0 15:33.4 10.205.10.58 10.203.12.144 58221 > irdmi [PSH, ACK] Seq=1 Ack=1 Win=64400 Len=1046 15:33.5 10.203.12.144 10.205.10.58 irdmi > 58221 [ACK] Seq=1 Ack=1047 Win=5246 Len=0 15:33.7 10.203.12.144 10.205.10.58 irdmi > 58221 [PSH, ACK] Seq=1 Ack=1047 Win=5246 Len=1232 15:33.9 10.205.10.58 10.203.12.144 58221 > irdmi [ACK] Seq=1047 Ack=1233 Win=63168 Len=0 15:53.1 10.205.10.58 10.203.12.144 58221 > irdmi [PSH, ACK] Seq=1047 Ack=1233 Win=63168 Len=1046 15:53.2 10.203.12.144 10.205.10.58 irdmi > 58221 [ACK] Seq=1233 Ack=2093 Win=6292 Len=0 15:59.6 10.203.12.144 10.205.10.58 irdmi > 58221 [PSH, ACK] Seq=1233 Ack=2093 Win=6292 Len=1232 //delay from previous frame is 19 Sec 15:59.8 10.205.10.58 10.203.12.144 58221 > irdmi [ACK] Seq=2093 Ack=2465 Win=64400 Len=0 16:03.4 10.205.10.58 10.203.12.144 58221 > irdmi [PSH, ACK] Seq=2093 Ack=2465 Win=64400 Len=1046 16:03.5 10.203.12.144 10.205.10.58 irdmi > 58221 [ACK] Seq=2465 Ack=3139 Win=7338 Len=0 16:07.7 10.205.10.58 10.203.12.144 58221 > irdmi [RST, ACK] Seq=3139 Ack=2465 Win=0 Len=0

(17 Aug '15, 18:34) pavil1985

Yes there is a huge gap. But the reason can't be seen in this screenshots. Have you checked the logfiles?

(18 Aug '15, 02:59) Christian_R