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

Acked data being resend sometimes

1

I have the following capture made via wireshark. For e.g. in line 96 it send the post request then it get OK ack in line 98. Again in line 99 it keep sending the same thing. I have check my application is only sending it ones. What could be going on at the network layer? I dont see the repetition at the application layer. Because if its a bug in my app then it should be always repeating it. But it happens only sometimes. Just to add on those without problem I notice this [ACK] Seq=1. The value is always 1 for the Seq and with those there is not repetition?

96  375.163057921   *.*.*.23   
*.*.*.12    HTTP/XML    592 POST /*********.asmx?WSDL HTTP/1.1  
97 
375.166722899   *.*.*.12    *.*.*.23    TCP 66  80?56912 [ACK] Seq=3068 Ack=1819 Win=130304 Len=0 TSval=18755499 TSecr=1624042020 
98 
375.244932864   *.*.*.12    *.*.*.23    HTTP/XML    714 HTTP/1.1 200 OK  
99 
375.244987515   *.*.*.23    *.*.*.12    TCP 66  56912?80 [ACK] Seq=1819 Ack=3716 Win=25600 Len=0 TSval=1624042102 TSecr=18755506 
100
375.302667374   *.*.*.23    *.*.*.12    TCP 449 [TCP segment of a reassembled PDU] 101 375.302702201   *.*.*.23   
*.*.*.12    HTTP/XML    592 POST /*********.asmx?WSDL HTTP/1.1  
102
375.306998164   *.*.*.12    *.*.*.23    TCP 66  80?56912 [ACK] Seq=3716 Ack=2728 Win=131328 Len=0 TSval=18755513 TSecr=1624042160 
103
375.399607915   *.*.*.12    *.*.*.23    HTTP/XML    714 HTTP/1.1 200 OK  
104
375.399705590   *.*.*.23    *.*.*.12    TCP 66  56912?80 [ACK] Seq=2728 Ack=4364 Win=26880 Len=0 TSval=1624042257 TSecr=18755522
105
375.456699174   *.*.*.23    *.*.*.12    TCP 449 [TCP segment of a reassembled PDU] 106 375.456734111   *.*.*.23   
*.*.*.12    HTTP/XML    592 POST /*********.asmx?WSDL HTTP/1.1  
107
375.463896220   *.*.*.12    *.*.*.23    TCP 66  80?56912 [ACK] Seq=4364 Ack=3637 Win=130304 Len=0 TSval=18755528 TSecr=1624042314

asked 21 Oct '15, 10:02

newbie14's gravatar image

newbie14
26338
accept rate: 0%

edited 21 Oct '15, 10:19

1

Could you provide us a trace at public accessible place?

(21 Oct '15, 11:00) Christian_R

I dont get you what trace do you need please ?

(21 Oct '15, 11:03) newbie14

The pcap file, from which you get the txt output.

(21 Oct '15, 12:09) Christian_R

The problem it has all the ip address which I could not disclosed. But what is your say on the fast retransmit?

(21 Oct '15, 19:15) newbie14
1

Use TraceWrangler, available from www.tracewrangler.com, to anonymize the IP addresses.

(21 Oct '15, 21:44) Jim Aragon

One Answer:

0

Maybe someone has another idea, but it seems as though the ACKs do different things.

  1. the first ACK (97) has Seq=3068 and Ack=1819
  2. the second (102) has Seq=3716 Ack=2728

ACKs are also sent when a packet has not arrived to signal a need to resend. In that case, the Ack field contains the last correctly received packet. Thus, the first might be a "send the data again", while the second might be a "ok, it has all arrived".

This is called fast recovery and fast retransmit. It is part of TCP's error recovery mechanism.

Different purposes of ACKs:

  • window scaling
  • retransmit
  • data acknowledgement

Sometimes the packets also cross on the layer (an ACK being sent to retransmit while the other packet is in transit).

In your case, have you considered posting the code at some Programmer's site (or here, if need be). Maybe it sends the data several times in some corner cases...

answered 21 Oct '15, 10:40

user1234's gravatar image

user1234
56237
accept rate: 50%

edited 01 Nov '15, 10:07

@user1234 I dont quite get you on the ack and seq=3068. If you say data have not arrived then why does the the other send 98 375.244932864 ...12 ...23 HTTP/XML 714 HTTP/1.1 200 OK to say that is has received the data. But I notice the seq is not 1 but all those with normal flow the seq=1. How to diagnose based on the sequence 1?

(21 Oct '15, 11:05) newbie14

That '200 OK' is the application layer talking. We're talking about retransmission at the transport layer. Dig out your OSI model book to get the difference.

(21 Oct '15, 22:46) Jaap ♦

My confusion is that why the application layer is sending the OK. It can only send if the earlier packet have reached meaning the packet send succesfully so why there is a retransmission then?

(22 Oct '15, 19:58) newbie14

@newbie14: Yes, you were right. In this case (different ack/seq-numbers), the ACKs should acknowledge different data packets. So from the trace it seems as though the application is asked three times and responds three times.

(12 May '16, 03:39) user1234