On Wed, 2009-01-28 at 17:33 +0100, [email protected] wrote: > As far as I know, this is exactly what is supposed to happen under a SYN > flood attack. The interesting point is whether lwIP correctly handles > the timeouts of the half-open PCBs and eventually closes them. If so, > the device should behave normally again. But as I said, unfortunately I > have no idea of the time span here... I guess Kieran or Jifl could help > out with that value.
The above sounds correct to me. A very quick calculation suggests the timeout is of the order of 10 minutes, but I've not checked my maths, and depends on what TCP_MAXRTX has been set to. I notice when looking at the code that we treat PCBs in the SYN_SENT state differently to those in the SYN_RCVD state, and have a different TCP_SYNMAXRTX value to limit the number of times a SYN is transmitted in SYN_SENT. SYN_RCVD is treated just like a fully open connection. I'm not sure this is right, but the only difference is how long the timeout is, so it's probably not the source of the this problem. The other reason why we'd not correctly time out a connection is if we'd decided to do zero-window probes instead of retransmission. This is relatively recent code, so could be to blame, but a 5 minute audit doesn't show up anything obviously wrong with it. It should be easy to rule out with a packet capture after the SYN attack has finished. i.e. Is lwIP retransmitting the SYN-ACKs, or is it sending zero-window probes, or is it sending nothing? I think that would be a useful thing to try. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
