public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] FreeBSD TCP/IP stack: robustness against SYN flood
@ 2008-03-27 14:39 Chad Handrich
  0 siblings, 0 replies; only message in thread
From: Chad Handrich @ 2008-03-27 14:39 UTC (permalink / raw)
  To: ecos-discuss

Hello,

It appears FreeBSD is unable to handle SYN floods.  My configuration is 
as follows:

stack:  FreeBSD
stack settings:
    CYGPKG_NET_MAXSOCKETS = 32
    CYGPKG_NET_MEM_USAGE = 294912
    CYGPKG_NET_MEMPOOL_SIZE = 73728
    CYGPKG_NET_MBUFS_SIZE = 73728
    CYGPKG_NET_CLUSTERS_SIZE = 147456
    CYGPKG_NET_NUM_WAKEUP_EVENTS = 16
CPU:  PowerPC405, 200MHZ
application on eCos:  /packages/net/common/current/tests/server_test.c
eth0 IP Address:  192.168.0.175
eth1 IP Address:  89.89.200.175

server_test.c is a simple server.  After loading the application, I can 
ping eth1 from my Linux computer just fine.

Then I run:
nmap -n -v -r -p- 89.89.200.175

This causes a massive SYN flood on all ports.  In a Wireshark packet 
analysis, you can see that the ecos application is returning a RST for 
each SYN it receives.  However, you can also see that several SYN's are 
received per RST that is returned (eg: the ecos application can't send 
RST's as fast as SYN's are being received).  Eventually, after about 27 
resets, the ecos application stops pinging and never will unless I reset 
the board. 

However, the other ethernet port (eth0) on my board will still ping.  So 
the application did not crash.  It just appears that the interface for 
89.89.200.175 is hung (maybe out of mbufs?)

The ecos output from when the SYN flood begins appears as follows (note 
that assertions is enabled in my ecos configuration, but no assertions 
are output):

Net malloc[148] = 0x000fcfe0
Net malloc[88] = 0x000fcf70
Net malloc[16] = 0x000fcf50
Net malloc[20] = 0x000fcf30
Alloc mbuf = 0x0010aa80
Alloc mbuf = 0x0010ab00
Alloc mbuf = 0x0010ab80
Alloc mbuf = 0x0010ac00
Alloc mbuf = 0x0010ac80
Alloc mbuf = 0x0010ad00
Alloc mbuf = 0x0010ad80
Alloc mbuf = 0x0010ae00
Alloc mbuf = 0x0010ae80
Alloc mbuf = 0x0010af00
Alloc mbuf = 0x0010af80
Alloc mbuf = 0x0010b000
Alloc mbuf = 0x0010b080
Alloc mbuf = 0x0010b100
Alloc mbuf = 0x0010b180
Alloc mbuf = 0x0010b200
Alloc mbuf = 0x0010b280


Then I modify nmap to place a 1ms delay between each SYN as such:
nmap --scan_delay 1 -n -v -r -p- 89.89.200.175

A wireshark analysis shows the ecos application returning a RST after 
every SYN it receives.  It shows no signs of "falling behind" (eg: 
several SYN's in a row between each RST).  The port scan completes 
successfully, and the ecos application still pings.  The output of the 
ecos application in this test case is different:

Net malloc[148] = 0x000fcfe0
Net malloc[88] = 0x000fcf70
Net malloc[16] = 0x000fcf50
Net malloc[20] = 0x000fcf30

It is exactly the same as the previous output, but no "Alloc mbuf" lines 
are present.

So my guess is that, in the first failing test, the FreeBSD stack is 
allocating and running out of mbufs, and never releasing them.

My final question is:  is there a known problem with mbufs (or something 
else that could cause an interface to go offline) in FreeBSD?  Can 
anyone recommend a solution to this problem?

My thanks,

Chad


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-03-27 14:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-27 14:39 [ECOS] FreeBSD TCP/IP stack: robustness against SYN flood Chad Handrich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).