Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods
From: Jesper Dangaard Brouer <hidden>
Date: 2012-05-30 22:40:55
From: Jesper Dangaard Brouer <hidden>
Date: 2012-05-30 22:40:55
On Wed, 2012-05-30 at 10:53 +0200, Christoph Paasch wrote:
On 05/30/2012 10:44 AM, Jesper Dangaard Brouer wrote:quoted
quoted
quoted
Then the receiver will receive two SYN/ACK's for the same SYN with different sequence-numbers. As the "SYN cookie SYN-ACK" will arrive second, it will be discarded and seq-numbers from the first one will be taken on the client-side.I thought that the retransmitted SYN packet, were caused by the SYN-ACK didn't reach the client?Or, if the SYN/ACK got somehow delayed in the network and the SYN-retransmission timer on the client-side fires before the SYN/ACK reaches the client.
That seems like a very unlikely situation, which we perhaps should neglect as we are under SYN attack. I will test the attack vector, if we instead of dropping the reqsk, fall back into the slow locked path.