[email protected] wrote: > The memp err simply says all TCP PCBs are in use. The expected behaviour > would be that every SYN leads to allocating a PCB and a SYN+ACK is sent > back. However, with a SYN flood attack, the originator does not respond > to that SYN+ACK (as it normally would, with an ACK). Instead, the PCBs > are left in a half open state and lwIP should retransmit the SYN+ACK > until a timeout occurs (don't know how long that is). Until that timeout > has occurred, lwIP will not process any new connection (due to lack of > resources, i.e. PCBs). > > 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.
include/lwip/tcp.h has this hard-coded: #define TCP_SYN_RCVD_TIMEOUT 20000 /* milliseconds */ This is processed in the TCP slow timer. Hmm, I also see there's code in tcp.c:tcp_kill_prio() to try and kill the oldest connection (in any state) after an inactivity timeout[1]. One could suggest this is a bad response to a SYN flood. Although in normal operation it's a good way to purge inactive connections. Perhaps there should be an inactivity floor which needs to be exceeded. There is a way to set PCBs to a higher priority than normal, and so not be killed off, but that's only really available to raw API users. And it does not discriminate between which active connections - perhaps pcbs with state SYN_SENT/SYN_RCVD should be killed off first, before ESTABLISHED (I'm not sure about the other closing states before ESTABLISHED, except for TIME_WAIT which is already handled). I think something could be improved here anyway. Perhaps a task should be submitted on savannah if no-one wants to look at it immediately. Jifl [1] The comment in it does not seem to match the code - it says it kills the oldest active connection lower than the supplied prio, but it's actually less than *or equal to* prio. -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
