From owner-freebsd-ipfw@FreeBSD.ORG Sun Jun 11 20:20:33 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C9216A418; Sun, 11 Jun 2006 20:20:33 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 526DF43D48; Sun, 11 Jun 2006 20:20:33 +0000 (GMT) (envelope-from vadim_nuclight@mail.ru) Received: from [82.211.136.13] (port=16189 helo=nuclight.avtf.net) by mx6.mail.ru with esmtp id 1FpWQ5-000K4p-00; Mon, 12 Jun 2006 00:20:29 +0400 Date: Mon, 12 Jun 2006 03:19:44 +0700 To: "Joao Barros" References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: freebsd-isp@freebsd.org, "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-ipfw@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:20:34 -0000 11.06.06 @ 22:36 Joao Barros wrote: Original message is at: http://lists.freebsd.org/pipermail/freebsd-current/2006-June/063821.html > I'm very interested in this, great work! :-) > I can't load the kld on my Sun Sparc, I think I messed up ld yesterday > trying to patch for a bug that show's in firefox and mozilla. It > compiles, just doesn't run. As soon as I have it up and running I'll > give you feedback. Umm, that's a kernel module, it shouldn't have any relations with ld. What diagnostics has it said on failed load? > Have you tested it with pf? If so can you give me some examples? No, it wasn't tested with pf. The problem with pf is that pf compiles all the rules at the time, so exact tags representation can change each time (for this reason ipfw tags were made incompatible with pf), and you must that values to supply them to . However, if you find a method how to obtain tag values info from in-kernel pf structures, you'll be able to use it with pf. It doesn't support well integration with netgraph, though. Another option is to use ipfw - it supports pf's altq(4) shaping, if that is all you need. > I'm particularly interested in this for doing packed shaping, especially > on P2P. Yes, I'm also looking for possibility of shaping, but I can't test (no resources) it currently. Also, as it seems non-trivial on current ipfw dynamic rules implementation, I don't know if shaping will work at all. But you can try to test such ruleset (it supposes that dynamic rules are checked twice, on incoming packets and on outgoing also, as with all other rules as ipfw manpage says): # first, split traffic to incoming to our router and outgoing ipfw add 100 skipto 600 ip from any to any out # check-state for incoming packets will catch all already matched # p2p connections, and continue to "tag 412" rest of them ipfw add 200 check-state # pass yet unrecognized incoming traffic to netgraph for analyzing # note that only one packet for connection will be tagged, not others # in the flow! ipfw add 300 netgraph 41 ip from any to any # XXX more limits? # let's create a state dynamic rule after one tagged packet - dynamic # rules only match addresses and ports, and then use parent rule to # determine action, and will also "tag 412" for every next packet # in that connection, so that's the way how we can catch packets on output # from our router ipfw add 400 pass tag 412 ip from any to any tagged 412 keep-state # this is the point where all other unmatched incoming traffic goes so # it must caught here or it will be matched for next rule, but next rule # should match outgoing traffic only ipfw add 500 pass ip from any to any # here is output were all packets which belong to p2p connections are # tagged 412 by dynamic rules, so we can send them all to pipe (or you # can use altq(4) here, of course).. the only thing to note that packets # to both directions of our router are sent to only one pipe, but for # my example it's enough ipfw add 600 pipe 40 ip from any to any tagged 412 -- WBR, Vadim Goncharov