Ask Your Question
0

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

asked 2018-09-21 03:52:30 +0000

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

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-09-22 16:14:15 +0000

mrEEde gravatar image

updated 2018-09-27 10:56:37 +0000

grahamb gravatar image

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

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: 2018-09-21 03:52:30 +0000

Seen: 98 times

Last updated: Sep 27