Server is not responding on SYN packets

packet-capturetcptcpdumptcpipwireshark

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):

Best Answer

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).

Related Solutions

Linux – Why would a server not send a SYN/ACK packet in response to a SYN packet

We had this exact same problem. Just disabling TCP timestamps solved the problem.

sysctl -w net.ipv4.tcp_timestamps=0

To make this change permanent, make an entry in /etc/sysctl.conf.

Be very careful about disabling the TCP Window Scale option. This option is important for providing maximum performance over the internet. Someone with a 10 megabit/sec connection will have a suboptimal transfer if the round trip time (basically same as ping) is more than 55 ms.

We really noticed this problem when there were multiple devices behind the same NAT. I suspect that the server might have been confused seeing timestamps from Android devices and OSX machines at the same time since they put completely different values in the timestamp fields.

No response to some SYN packets when timestamps are enabled

In my case the following command fixed the problem with missing SYN/ACK replies from Linux server:

sysctl -w net.ipv4.tcp_tw_recycle=0

I think it is more correct than disabling TCP timestamps, as TCP timestamps are useful after all (PAWS, window scaling, etc).

The documentation on the tcp_tw_recycle explicitly states that it is not recommended to enable it, as many NAT routers preserve timestamps and thus PAWS kicks in, as timestamps from the same IP are not consistent.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Best Answer

Related Solutions

Linux – Why would a server not send a SYN/ACK packet in response to a SYN packet

No response to some SYN packets when timestamps are enabled

Related Topic