This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

FreeBSD TCP/IP stack: robustness against SYN flood


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]