Ask Your Question
0

Unusual delay during TCP connection handshake

asked 2019-09-06 16:18:23 +0000

rpadrela gravatar image

updated 2019-09-06 21:46:58 +0000

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?

edit retag flag offensive 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 gravatar imagegrahamb ( 2019-09-06 16:31:22 +0000 )edit

Captures added.

rpadrela gravatar imagerpadrela ( 2019-09-06 17:06:16 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-09-10 21:03:01 +0000

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-09-06 16:18:23 +0000

Seen: 70 times

Last updated: Sep 10