Date: Fri, 8 Sep 2006 08:16:45 -0500 From: "Bill Marquette" <bill.marquette@gmail.com> To: "Rajkumar S" <rajkumars@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: NEW IDEAS Message-ID: <55e8a96c0609080616r61f28321y59a41ad207ee4d4c@mail.gmail.com> In-Reply-To: <64de5c8b0609072343h19cc40aaked48adb4d9a0b48e@mail.gmail.com> References: <19710703252.20060907212112@yandex.ru> <200609072125.25957.max@love2party.net> <64de5c8b0609072343h19cc40aaked48adb4d9a0b48e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/8/06, Rajkumar S <rajkumars@gmail.com> wrote: > On 9/8/06, Max Laier <max@love2party.net> wrote: > > On Thursday 07 September 2006 20:21, KES wrote: > > > Archie Cobbs <archie@dellroad.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55e8a96c0609080616r61f28321y59a41ad207ee4d4c>