Ask Your Question
0

ACK from server not received by client

asked 2020-11-25 16:18:53 +0000

undergl gravatar image

updated 2020-11-25 16:50:13 +0000

grahamb gravatar image

Hi, Can anyone help me to understand this captures?

client 72.189.226.91 server 192.168.78.118 port 8086

Client report random connection problem on connect to server port 8086. I attach the anon captures

For example (one error time):

Captures at Client side (client_side_anon.pcapng)

2020-11-11 12:39:49,591869  72.189.226.91   192.168.78.118  TCP 74  43188 → 8086 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=739647657 TSecr=0 WS=64

The server doesn't response to this SYN with an ACK (really yes but it does not receive it, see below the capture on the server)

Client request again

2020-11-11 12:39:52,595107  72.189.226.91   192.168.78.118  TCP 74  [TCP Retransmission] 43188 → 8086 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=739648408 TSecr=0 WS=64

...

at this point fail.

Captures at Server side (server_side_anon.pcacpng) The SYNC is received by the server

2020-11-11 12:39:49,599532  72.189.226.91   192.168.78.118  TCP 74  43188 → 8086 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=739647657 TSecr=0 WS=64

and it response with ACK

2020-11-11 12:39:49,599568  192.168.78.118  72.189.226.91   TCP 66  8086 → 43188 [ACK] Seq=1 Ack=2413873066 Win=249 Len=0 TSval=190156218 TSecr=697151199

But this ACK is never seen at client side

Why this ACK i not received by the client side and it requet again? and the server resends it ... and so on. TCP Retransmission Where can the problem be here?

Captures: Capture 1 Capture 2

edit retag flag offensive close merge delete

Comments

First off. If you pose a qeuestion like this it might be usefull if you can point to a specific stream. That always helps a lot to carve down the issue.

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2020-11-25 17:11:49 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-11-25 18:31:39 +0000

hugo.vanderkooij gravatar image

updated 2020-11-25 18:33:58 +0000

If I look with a filter like "tcp.port == 43188" then I am suddenly reminded about 2MSL issues.

While the timing does not warrant it as I have never seen an issue before where a re-use of a port combinaton is an issue after 120 seconds silence. The results seem to indicate that the server might have an issue there.

I would focus on port re-usage issues for now.

If you have access to the server you may also want to look at the output of netstat -nat and see if you have Time-Wait for a long time on the port where you don't get the expected SYN-ACK response.

edit flag offensive delete link more

Comments

Hi, Hugo, thanks for your help... I'm going to check netstat at server side.

If I don't wrong, you are thinking in a old connection in "Time-Wait" state in the same port 43188, when new connection using same source port 43188 send SYN packet the server reply to the old connection. Is this?

Filtering tcp.port eq 43188 I saw that same source port is used at 11:08 and reused at 12:39

The problem is at server? Why have 43188 connection open for more than 1 hour and a half

Other error is produced at 13:03:04 and same source port was used at 8:28:31

Many thanks

undergl gravatar imageundergl ( 2020-11-26 05:54:30 +0000 )edit

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: 2020-11-25 16:18:53 +0000

Seen: 1,070 times

Last updated: Nov 25 '20