From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:59:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B80106564A for ; Fri, 1 Aug 2008 15:59:07 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id BB9058FC1B for ; Fri, 1 Aug 2008 15:59:06 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 25841 invoked from network); 1 Aug 2008 12:59:05 -0300 Received: by simscan 1.1.0 ppid: 25833, pid: 25834, t: 0.4594s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.0 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 12:59:05 -0300 Message-ID: <4893328C.2040105@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 12:58:04 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Julian Elischer References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> In-Reply-To: <48922E9D.1020507@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:59:07 -0000 Julian Elischer escreveu: > Patrick Tracanelli wrote: >> Mike Makonnen escreveu: >>> Hi, >>> >>> An Internet Cafe I do some work for was recently having problems with >>> very slow internet access. It turns out customers were running P2P >>> file sharing applications which were hogging all the bandwidth. I >>> looked for programs that would allow me to shape traffic according >>> to the application layer protocol, but couldn't find any for FreeBSD. >>> I found a couple: l7-filter and ipp2p, but these are Linux specific. >>> So, I decided to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >>> >>> As the name implies it uses ipfw(4) to implement a userland daemon >>> that classifies TCP and UDP packets according to regular expression >>> patterns for various protocols. It's intended to be used with >>> divert(4) sockets and dummynet(4) so you can do traffic shaping >>> depending on the application level protocol. The protocol patterns >>> are from the l7-filter project. >>> >>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >>> reads its configuration file for a list of protocols and ipfw(8) >>> rules. Then, when it detects a matching session it re-injects the >>> packet back at the specified rule number. The tarball has a sample >>> configuration file and firewall script to get you started. >>> >>> While I have not done extensive testing, preliminary tests are >>> encouraging and it seems to work, so I thought I'd announce it to the >>> rest of the world in case anyone else is interested in this kind of >>> application. >>> >>> Comments and suggestions highly appreciated. >>> >>> Cheers. >> >> Wont compile on RELENG_6 but is working perfectly on REL_7. I am >> trying hard with ssh, soulseek and msn. Its working like a charm with >> the suggested rc.firewall. >> >> I have configured ipfw-classfyd.conf changing the rules, for a number >> of L7 patterns, and now I try to understand why the "diverted" rules >> only match if the rule number is 1 after the configured, ie, I put >> soulseek to 65530 and a rule wont match there, but the very same rule >> matches 65531. I will read the code, but it seems that reinjection of >> the packet is made +1, correct? > > > yes, > the idea is: > If you get the sockaddr for the received packet, and use it unmodified > when reinjecting the packet, > then it will continue on at the next rule. > so since the rule number is "unchanged" we need to add 1 to it > to say where to start from.. > > hope that helps.. Perfect. Thanks. 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 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%. So far, this is what I have in real world enviroments. -- Patrick Tracanelli