Date: Sat, 02 Aug 2008 16:00:41 +0300 From: Mike Makonnen <mtm@wubethiopia.com> To: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> Cc: freebsd-net@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: Application layer classifier for ipfw Message-ID: <48945A79.50300@wubethiopia.com> In-Reply-To: <4894447C.3000800@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Makonnen wrote: > Patrick Tracanelli wrote: >> >> To let you know of my current (real world) tests: >> >> - Wireless Internet Provider 1: >> - 4Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> - Classifying 100Mbit/s of dump over ssh >> >> Results in: >> No latency added, very low CPU usage, no packets dropping. >> >> - Wireless ISP 2: >> - 21 Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> >> Results in: >> No tcp or udp traffic at all; everything that gets diverted never >> comes out of the divert socket, and ipfw-classifyd logs >> >> Aug 1 12:07:35 ourofino last message repeated 58 times >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >> (rule 1000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >> 50000) >> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >> socket: Operation not permitted >> Aug 1 12:18:50 ourofino last message repeated 90 times > > Hmmm... this part means that the call to sendto(2) to write the packet > back into network stack failed. This explains why you are not seein g > any traffic comming back out of the divert socket, but I don't see why > it would suddenly fail with a permission error. Could this be a kernel > bug? >> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >> full >> Aug 1 12:19:11 ourofino last message repeated 94 times >> >> Raised queue len a lot (up to 40960), when the application starts it >> uses up to 25% CPU and a second after that, CPU usage gets lower the >> 0.1%. > > This looks like a deadlock. If it weren't able to process packets fast > enough the cpu usage should be high even as it's spewing "packet > dropped" messages. Can you send me some more information like memory > usage and the firewall script you are using? How much of the 21Mbits/s > of traffic is P2P? If you reduce the number of protocols you are > trying to match against does the behavior change? Using netstat -w1 > -I<interface> can you tell me how many packets per second we're > talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the > log file seem to show that the daemon is running for approx. 34 sec. > before the first "unable to write to write to divert socket" message. > Is it passing traffic during this time? Thanks. > > I've uploaded a newer version. Can you try that also please. It includes: > o SIGHUP forces it to re-read its configuration file > o rc.d script > o minor optimization (calls pthread_cond_signal with the mutex > unlocked) > o code cleanup > > Also, for your convenience I have attached a patch against the earlier > version that removes a debugging printf that should remove spammage to > your log files (the current version has it removed already). > Ooops, a few minutes after I sent this email I found a couple of bugs (one major, and one minor). They were in the original tarball as well as the newer one I uploaded earlier today. I've uploaded a fixed version of the code. Can you try that instead please. Also, to help track down performance issues I've modified the Makefile to build a profiled version of the application so you can use gprof(1) to figure out where any problems lie. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48945A79.50300>