0

On the attached tcp dump, the first two SYN packets (#21800 and 21801) came to the server, however SYN ACK was sent for the second SYN. Is that correct behaviour? My understanding is that the client is trying to establish two TCP connections from different src ports, so both connections should have been established. After 4 retries the client changed its src port from 13158 to 2352, and the TCP connection succeeded. Is this an issue on the client or server side?

Similar article below doesn't seem to be related. Why would a server not send a SYN/ACK packet in response to a SYN packet

TCP Dump (client IP masked):

https://www.dropbox.com/s/3qkh1jw8emimh21/tcpdump1.png?dl=0

Community
  • 1
sidorvm
  • 1
  • 1

1 Answers1

0

Seems to be an issue on the server side. The client retransmitted the initial packet around 16:30:44 (the black sequence of lines on your screenshot) and the server finally replied. So it appears the very first packet was either lost on the server side, or server could not handle it properly for some reason (listen queue overflow, not enough workers, CPU saturation or something else).

drookie
  • 8,051
  • 1
  • 17
  • 27
  • Server finally replied only after the client changed src port# and after existing connection was tiered down. Even if there is an existing TCP connection between client and server, new SYN packet should be accepted with no issues right? – sidorvm Feb 18 '15 at 03:07
  • Yup. I don't see a connection between client port changing and successful handshake (but may be there is, like bad packet filter rule), so I'd insist on packet losses, because it's way more usual. – drookie Feb 18 '15 at 10:36