Date: Fri, 8 Sep 2006 12:13:12 +0530 From: "Rajkumar S" <rajkumars@gmail.com> To: freebsd-pf@freebsd.org Subject: Re: NEW IDEAS Message-ID: <64de5c8b0609072343h19cc40aaked48adb4d9a0b48e@mail.gmail.com> In-Reply-To: <200609072125.25957.max@love2party.net> References: <19710703252.20060907212112@yandex.ru> <200609072125.25957.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. raj
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64de5c8b0609072343h19cc40aaked48adb4d9a0b48e>