From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:50:18 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 861D5106566B for ; Fri, 1 Aug 2008 15:50:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 55B4D8FC1E for ; Fri, 1 Aug 2008 15:50:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1480992rvf.43 for ; Fri, 01 Aug 2008 08:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jWjSTD/A5EDTp2XgaPrB+D4Y6tPKz3groDfrnBo53+k=; b=q/In9/5AFlQOhM/4RlDm4p0eFzNpouexFEGU7mXRAfezGviMtY3L9DQKDLTKa4Cn4B 6gw1+suXmZqx2v9AXc3R8VnO6+lF8r8Y1UXdclvdv/np1F+1br0uaNqacjhLJ2BXyoHW T+ZNgE0h9AwyNGnG91q9YMSSbHZR7RBJ02xcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=yHKAQVLeTGOmz4p03ZjMz1CFl9sLr4gnoEMMrRtHEuerCZaA97cW684pylk/OBvqY5 QKw2clioOtLPOnFsEgDs9RIzmmxDNkUfJUU0tTAqFykTXAUOAbJxD2StbNxZDS13Uuf6 XnOi4dGTTAZYf67pjx1pIVifXHhYVIFWA+if8= Received: by 10.140.128.11 with SMTP id a11mr6022228rvd.232.1217605817727; Fri, 01 Aug 2008 08:50:17 -0700 (PDT) Received: by 10.141.128.2 with HTTP; Fri, 1 Aug 2008 08:50:17 -0700 (PDT) Message-ID: <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> Date: Fri, 1 Aug 2008 17:50:17 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Mike Makonnen" In-Reply-To: <4892E3BE.2030900@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> <4892E3BE.2030900@wubethiopia.com> Cc: 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:50:18 -0000 On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen wrote: > Ermal Lu=E7i wrote: >>> >>> 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 decide= d >>> 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-filte= r >>> 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. >>> >> >> Thanks for this. >> I have a question, you remove a flow from if you see a FIN for the TCP >> case and only on overlapping flow for either TCP/UDP how do the other >> flows expire i am missing that part? >> >> > > No, you're not missing anything. It's on my TODO list. I wanted to get > this out and get feedback as early as possible, so I released it as soon = as > I had it basically working. I'm thinking of storing some session > information > for the flow (like a timestamp for the last packet seen) and implementing > a garbage collector thread that removes sessions that have been idle for > some period of time. > BTW, why not make it a port?! --=20 Ermal