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

a 30+ second delay

0

I have a linux server which I test by sending thousands of calls to get a JS file. The problem is that every few hundreds (sometimes thousands) calls, I get a delay of ~30 seconds. It happens only when the client is OSX (never on windows). Attached is a wireshark capture of two consecutive sessions. I've noticed that while the port number of the second session's SYN request (Frame 12) is 55295, the destination port of the SYN-ACK (Frame 13) is 55199, the port of the first session. I guess that's why when the server sends SYN-ACK he gets RST, because the client already closed the first session. As for the second session, because the client did not receive the SYN-ACK, it keeps retransmitting SYN. Did I get it right? What can be a solution on the server side? http://i.stack.imgur.com/eZezJ.png alt text

asked 19 Nov '14, 00:36

Eran%20Raichel's gravatar image

Eran Raichel
1112
accept rate: 0%

edited 19 Nov '14, 00:46

Hi,If you see on packet no. 12 client sends syn request and after mulitple retransmissions in packet no. 40 after 36 seconds server responds with syn ack.So if possible do capture on both ends to have more precise answer.

(19 Nov '14, 06:38) kishan pandey

One Answer:

0

Frame #13 (and the consecutive re-transmissions of it) is the problem.

As you can see, that frame contains the same SYN-ACK of frame #2, however with a totally wrong SEQ/ACK number. It should be SEQ=0, ACK=1. What we see is SEQ=69452, ACK=367003392. That's wrong and that's the reason why Wireshark flags the frame and why the receiver sends a RESET. The reson for this behaviour is unclear and you won't find it in the capture file. Maybe the system itself (38.126.142.158) has a problem or a device "on the way" alter (or generates) those frames, like a firewall, load balancer, wan accelerator, etc.

Regards
Kurt

answered 20 Nov '14, 02:00

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks Kurt for your answer, I also see that the seq/ack are wrong. what about the wrong destination port? any idea? BTW, this is how it looks with absolute seq numbers: alt text

And this is the TCP session (port 55199) that was used a few seconds before, been closed, but for some reason the server uses it to send the SYN, ACK alt text

(20 Nov '14, 02:09) Eran Raichel

what about the wrong destination port? any idea?

As I said. You won't find the reason for that behaviour in the capture file. It could be one of the things I mentioned.

And the wrong SYN-ACK isn't necessarily a response to the second SYN (port 55294). Maybe it's just a resend of the original SYN-ACK (port 55199) and then there is no "wrong destination port" ;-)

(20 Nov '14, 02:14) Kurt Knochner ♦