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.
Ask Your Question
0

[TCP Handshake]Server respond ack only instead of syn/ack

Hi Experts

I encountered an TCP handshake issue. Client initiated SYN(No.1 & 2) to server, however server responded an ACK(No.3) not SYN/ACK, but after that the server send a SYN/ACK(No.6) back to client.

According to pcap, it seems client retransmission the SYN till it RST this handshake. But somehow, the client try to re-establish the connection, and it worked normal as SYN , SYN/ACK , ACK.

My question is,

  1. What kind of situation will cause this issue happen?
  2. During handshake phase, what will client do if he received 2 ACKs ?

More Info:

  1. The dump is captured at server side interface.
  2. pcap file : https://dsc.cloud/CloudBucket/handsha...
  3. Image : https://dsc.cloud/CloudBucket/Screen-...

Sorry for that I don't have point to upload here

Thank you,

Tom

Tom Tang's avatar
1
Tom Tang
asked 2018-09-21 03:52:30 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

A few assumptions before I give it a try to explain what happens.

The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds

Here are the facts.

  • The client sends its initial SYN packet with a tcp.options.timestamp.tsval 4062472739
  • The server's intial SYN ACK gets lost - or was never sent.
  • The client retransmits with 1 second tcp.options.timestamp.tsval 4062473739
  • The client retransmits after 2 seconds tcp.options.timestamp.tsval 4062475739
  • The server retransmits its SYN_ACK with tcp.options.timestamp.tsecr 4062472739

As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting

Now to the answers.
Why the server does not accept in time can have multiple reasons.
Either the listener's backlog is full or
the server tries to reverse lookup the client's ip address
Or the SYN_ACK got dropped internally before it made it to the trace point.

If the client receives 2 ACKs during the handshake it should simply discard them. If it is a SYN_ACK and carries the correct TSEcr it should complete the 3-way handshake.

Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course

Regards Matthias

mrEEde's avatar
4k
mrEEde
answered 2018-09-22 16:14:15 +0000
grahamb's avatar
23.8k
grahamb
updated 2018-09-27 10:56:37 +0000
edit flag offensive 0 remove flag delete link
more

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