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

[TCP Previous segment not captured] something is lost in communication

0

Hello,

I am investigating strange behavior of one application. The problem from user point of view is described as follow: "There is web application with some form which has two buttons. When user is pressing one of them s(he) suppose to see some dialog. And in some scenario the problem is that it doesn't happen. Form just does not appear."

I have two Wireshark's logs, one for problematic scenario and one for successful. I uploaded them here:

failure: http://www.cloudshark.org/captures/d11077f00245 (the stream which i am checking is tcp.stream eq 111) success: http://www.cloudshark.org/captures/9e4b1c861030 (the stream which i am checking is tcp.stream eq 197)

Pushing the button is resulting in POST request: POST /service/sydney/load.php

I can see that in problematic scenario there are series of DUP ACKs and retransmit. It seems to me that there is ok-response from server in a form "HTTP/1.1 200 OK", but on some reason i do not see it as an individual trace in wireshark log, i can see it only among [TCP segment of a reassembled PDU] traces if i am checking their content. In successful log there is no any retransmit, there is "200 OK" confirmation and everything looks great. Did i get it correct that some of the ACK was missing or its number was not correct. Could anybody explain why it could be the possible reason for this to happen? Please help me to decrypt this part of traces [4509-4522] because I am not sure my interpretation is correct.

Thanks a lot in advance, Kristina

asked 09 Jan '14, 01:57

Chris_kh's gravatar image

Chris_kh
0●1●1●3
accept rate: 0%

One Answer:

1

It looks as if your client's TCP stack is not reading the segments hat the server is retransmitting

filter (tcp.ack == 256889 or tcp.seq == 256889) and tcp.stream==111 shows the windows client is asking for (relative) sequence number 256889 which the server is constantly re-transmitting - with increasing intervals but windows TCP is not reading/seeing it. The tcp checksum on the inbound segments is correct so there is no obvios reason to discard those segments.

alt text

answered 09 Jan '14, 10:38

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

edited 10 Jan '14, 02:38

Thank you for you reply! May i ask you what do you think could cause that DUP ACK series which appears in the log before that seq 256889? Could you "translate for me" frame 4509? Is all this situation until the [4558] looks ok?

(10 Jan '14, 01:06) Chris_kh
1

Duplicate ACKs are sent for every segment that arrives 'out_of_order'. This is a method to trigger a 'Fast Retransmission' where the sender should immediately retransmit when it receives the 3rd 'duplicate ack'. Frame 4509 is the first packet that arrives out_of_order. The expected sequence number after 4508 was 236025, what arrived was 237329. If you look at the ip.ids of 4508 and 4509 you will recognize that exactly 1 ip packet was lost: 0xd1ae

(10 Jan '14, 02:37) mrEEde

Thnx a lot for very detailed explanation, i got it now!

(10 Jan '14, 06:06) Chris_kh