From owner-freebsd-pf@FreeBSD.ORG Fri Sep 8 13:16:47 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F6AF16A4DA for ; Fri, 8 Sep 2006 13:16:47 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3435D43D49 for ; Fri, 8 Sep 2006 13:16:46 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so746948pye for ; Fri, 08 Sep 2006 06:16:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JCSHxTaoEKbDe5vKuWZaLAUD8l9KHozm+xhImSQf+8pNpyXfPhlDQSfVRErlnv/fb/O7F6DQkIjJyeiw8z2twrT1Ud641oCetdlVpb9As2Tb8tUgua3K5fL3XnFgtx3wFYX3d6oJrgSOE88PPqpUI/sQ/c6gn7laC14c/5/XGdA= Received: by 10.35.88.17 with SMTP id q17mr2900053pyl; Fri, 08 Sep 2006 06:16:45 -0700 (PDT) Received: by 10.35.131.17 with HTTP; Fri, 8 Sep 2006 06:16:45 -0700 (PDT) Message-ID: <55e8a96c0609080616r61f28321y59a41ad207ee4d4c@mail.gmail.com> Date: Fri, 8 Sep 2006 08:16:45 -0500 From: "Bill Marquette" To: "Rajkumar S" In-Reply-To: <64de5c8b0609072343h19cc40aaked48adb4d9a0b48e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19710703252.20060907212112@yandex.ru> <200609072125.25957.max@love2party.net> <64de5c8b0609072343h19cc40aaked48adb4d9a0b48e@mail.gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: NEW IDEAS X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2006 13:16:47 -0000 On 9/8/06, Rajkumar S wrote: > On 9/8/06, Max Laier wrote: > > On Thursday 07 September 2006 20:21, KES wrote: > > > Archie Cobbs wrote: > > > >>KES wrote: > > > > >> How about 'ALTQ' node? or may be 'queue' node > > > >> for packets scheduling > > > The problem is, how do you classify your traffic for queueing? i.e. where > > and how do you decide whether to put a given packet into queue A or B? > > Is it possible to have a netgraph hook for pf also? Some thing like > > queue in on dc0 from 192.168.0.0/24 to 192.168.0.1 > > Where the packet will be passed to a netgraph node with full state > information about the TCP stream. If the packet is dropped in netgraph > then it's as good as a block, other wise it's a pass. You can just delete the state using a pf ioctl - although that interface needs to be slightly modified so you can delete an individual state. > The idea is to have some sort of userspace processing for things like > blocking p2p. I can already take packets from ethernet interfaces, but > getting packets from pf has some advantages like: > > Ability to select which packets I want to pass to userspace > Take advantage of tcp reassembly and state tracking of pf. > > The state tracking is important because that can help in identifying > patters that span multiple packets in userspace easily. The pf > netgraph node can set tags as well as assign the packet to a > particular queue, for example slow down kazaa. > > I am not sure how much of this is feasible or even desirable, but just > thinking out loud. I've had other things to work on, so this has kind of stagnated (especially seeing as there's no userland tool to make use of it yet), but take a look at: http://www.pfsense.org/~billm/patches/billm-expose-queues.patch which in combination with the ability to update a given state would allow you to reclassify state entries. The idea behind it, is to track the queue assigned in the state entry instead of the rule that created that state entry (it includes a pfctl hack - and I do mean hack - to display the queue number assigned to the state). There are some obvious flaws in it...but they more or less exist in pf today (queue 1 is no longer a high priority queue after rule reload, but a low priority queue...guess what happens to your flow - assuming of course I actually understand the packet flow through altq enough). --Bill