From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17892 invoked by alias); 27 Mar 2008 14:02:33 -0000 Received: (qmail 17869 invoked by uid 22791); 27 Mar 2008 14:02:27 -0000 X-Spam-Check-By: sourceware.org Received: from connor.medar.com (HELO connor.medar.com) (206.181.246.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Mar 2008 14:02:04 +0000 Message-ID: <47EBA8DE.2080408@weldtechcorp.com> Date: Thu, 27 Mar 2008 14:39:00 -0000 From: Chad Handrich User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] FreeBSD TCP/IP stack: robustness against SYN flood X-SW-Source: 2008-03/txt/msg00175.txt.bz2 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