hi all tomorrow i will do other test using debugger. i have some doubts:
1. i have 3 listener in my code. lwip will use a TCP PCB for each listener? if yes, i need 6 TCP PCBs pbufs in lwipopts for managing 3 simultaneous connections. right? 2. i'm not sure, i have to check again, but it seems that lwip doesn't free TCP PCBs pbufs after open/close tcp operation with a pc app (i'm using 130) 3. i tested lwip with another scan tool, which performs a massive syn attack, producing half open connections, and after i cannot connect to listeners. i didn't wait for 10-20 minutes, to see if lwip exit from stuck.... tomorrow i will try a complete test. could be usefull a wireshark log during syn attack and after, during stuck? bye piero 2009/1/28, Jonathan Larmour <[email protected]>: > [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 > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
