I am new to TCP troubleshooting, Let me know if below mentioned analysis make sense. In frame 12100 the client tries to send a frame with sequence number 6154844. That sequence number was previously sent by the client in frame 12084. We can see that this as an out-of-order frame, is it possible that the clientdid not receive Server's ACK of that sequence number, and the client is retransmitting the frame? the TCP window size appears to be small for this session, so each packet sent by the client looks like it gets acknowledged before the client sends the next packet. This makes the retransmit scenario seem unlikely. Once the client resends sequence number 6154844, it keeps resending it. Server doesn't acknowledge it because it already has. The client retry count apparently gets exhausted and it attempts to restart the session in frame 12106. Server ignores the attempt to start a new session, as it already had a session with that IP address and port number. Refer image in link http://imgur.com/a/ebMSJ asked 27 Jan '17, 15:16  arunkumarkak edited 27 Jan '17, 15:19 |
2 Answers:
I think you are correct. The behaviour is explained by the client not receiving the ACKs. Can you capture at the client? I also notice that window size is small. Is the SYN - SYN/ACK in the trace file? Wireshark needs to see the handshake to get the window scaling factors and I suspect it doesn't have them. The evidence for this is that there are several packets from client to service of 1448 bytes even though the window size is showing as 1345. answered 28 Jan '17, 00:04  PaulOfford |
Hi, I wonder what was the environment you've captured in? Look at those timings! We're on receiving side. After receiving first data packet we ACK'ed it immediately, BUT got the next data packet after 9 (!) seconds.If client had not received our ACK, where is regular retransmissions which must be happening after maximum of 0.5 seconds? And this pattern is happening again and again throughout all the trace (screenshot). The first retransmission came to us after 28 seconds. TCP timestamps is of a GREAT help here. We observe the same Tsecr value of 992435503 in all data packets. This is a sign of all data packets being sent in response to only one our ACK. At the same time Tsval in data packets differs not much, that can be a sign of data packets being sent very closely one to another. It seems that packet train going from the client (10.9.129.22) is hanging somewhere on the highly congested and deeply buffered link. So congested and buffered, that we're receiving one packet every 'some' seconds. But all this packet train was emitted in very short period of time. Much later retransmission finally came to us (probably it was emitted after 0.2 seconds from original packet, but got to our side after 28 seconds). Here we have another dramatically change - all 3 retransmissions and some other packets from frame no.12094 came in time span less than millisecond. Maybe, congestion at this time was less than before. Unfortunately, we can't see full timestamp values - your screenshot is being cut from the right. Some other observations:
It's hihgly unlikely for client to start another TCP session with the same source port in such short period of time (unless it is hardcoded somehow). But again, we can't see that on the screenshot. Thanks for interesting sample! answered 28 Jan '17, 11:58  Packet_vlad edited 28 Jan '17, 12:17 THANKS GUYS. let me upload captured file. (28 Jan '17, 21:56) arunkumarkak |
It would be great if could share us the trace. As we are missing a lot of infos in screenshot. https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/