&gt; Window scaling was definitely on my radar, but IIRC the Linux SYN cookie implementation is supposed to encode if this TCP option is set in the initial SYN as well, so I don&#x27;t see how this would explain thing unless the implementation is broken.<p>Yeah, it&#x27;s supposed to be encoded, but it&#x27;s possible it&#x27;s broken. Given that you can reproduce it with a low somaxconn, it seems like the router wasn&#x27;t the problem, the router just was able to more easily trigger the problem.<p>&gt; I&#x27;m not sure if I understand what you&#x27;re saying about SYN+ACKs not being retransmitted, I think they should be if they get lost, it&#x27;s only the final ACK from the client that doesn&#x27;t get retransmitted if its lost, but that would cause different symptoms.<p>SYN+ACK will normally be retransmitted, but if you&#x27;re in synflood conditions, it means the kernel is going to throw away state for SYN+ACKs, and then it no longer has the state to retransmit.  It will reconstruct the state if it gets an ACK that is a decodable syncookie, or if it gets a retransmitted SYN, since it&#x27;ll make a new SYN+ACK for that (although that may end up with a different sequence number).