First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

Unusual delay during TCP connection handshake

  • retag add tags

Hi all,

I'm seeing an unusual delay (~5 seconds) on my client establishing a TCP connection to my server. I've done a Wireshark capture both on client and server and I can see on the client a delta time of 4+ seconds on the first frame it receives from the server immediately after the three-way handshake.

Another interesting thing, looking at the "time of arrival" for the 1st frame the client receives from the server ([SYN, ACK]), this timestamp is before the server even receiving the 1st frame ([SYNC]) from the client according to the server's capture. How is this possible? The clocks from the machines where the captures were done seem to be in perfect sync.

My account doesn't allow me to upload files yet, unfortunately. I'll find an alternative way to upload the captures if necessary.

Any feedback is welcome.

Thank you

Edit 1: I forgot to mention that this only happens when the client runs on a mobile phone using a specific carrier. I don't see this problem if I run the client on the same phone but using a different carrier.

EDIT 2: Captures added.

Server: https://www.dropbox.com/s/kyrt4vuur2i... (add filter (ip.addr eq 82.132.224.159 and ip.addr eq 192.168.1.65) and (tcp.port eq 9009)) Client: https://www.dropbox.com/s/ueftgffyy7m... (add filter (ip.addr eq 10.161.27.215 and ip.addr eq 146.199.123.130) and (tcp.port eq 9009))

Note that IP addresses and sequence numbers do not match from the two captures but it's the same TCP conversation. This is another peculiarity that only seems to happen when using this particular carrier.

EDIT 3: I guess that my client is doing the handshake with a device that acts as an intermediary, which later goes on to establish a connection with my server on behalf on my client. This would explain the interesting thing I mentioned about the time of arrivals from the captures not making sense. Has anyone seen this before? Any ideas on how to work around it?

rpadrela's avatar
1
rpadrela
asked 2019-09-06 16:18:23 +0000, updated 2019-09-06 21:46:58 +0000
edit flag offensive 0 remove flag close merge delete

Comments

To share captures, upload them to a public file share, e.g. Google Drive, DropBox etc, and then post a link to the files by editing your question.

grahamb's avatar grahamb (2019-09-06 16:31:22 +0000) edit

Captures added.

rpadrela's avatar rpadrela (2019-09-06 17:06:16 +0000) edit
add a comment see more comments

1 Answer

0

Yes you are right there is a delay of around 4.4 seconds in the trace. The gap is directly after the 3 way handshake. We see this delay only on the client side. Further I can spot that the initial SYN arrives at the server around 4 seconds later. Also I see the use of different IP Addresses in the traces (NAT). So my assumption is that one device in the middle (e.g. Firewall, Loadbalancer) is responsible for the delay

Christian_R's avatar
2.1k
Christian_R
answered 2019-09-10 21:03:01 +0000
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer