Application layer classifier for ipfw

[Ermal Luçi]

One thing, can you please make the SYN/ACK table optional since on
pf(4) you have the info from the state table when a tcp connection is
established.

On Sat, Aug 2, 2008 at 1:34 PM, Ermal Luçi <ermal.luci at gmail.com> wrote:
> On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen <mtm at wubethiopia.com> wrote:
>> Patrick Tracanelli wrote:
>>>
>>> eculp escreveu:
>>>>
>>>> Quoting Mike Makonnen <mtm at wubethiopia.com>:
>>>>
>>>>> Daniel Dias Gonçalves wrote:
>>>>>>
>>>>>> You will go to develop a version to work with PF ?
>>>>>>
>>>>> I don't know what's needed to get it to work with pf, but if it's not
>>>>> too
>>>>> much work, sure.
>>>>
>>>> That would be great, Mike.  I'm seeing more and more bandwidth being used
>>>> with p2p that I haven't been able to control with pf.  The thought has
>>>> entered my mind to change back to ipfw that I used for many years before
>>>> changing to pf maybe 3 years ago.  I also found dummynet to be easy and
>>>> practical to set up for both incoming and outgoing connections.  Something
>>>> else I haven't figured out how to do the same with altq, if even possible.
>>>>  In fact, if I am able to control p2p with pf I may not even need
>>>> bidirectional bandwidth limits.
>
> As for pf(4) i have mostly finished divert support on pf. The number
> on the protocol means a dummynet queue/pipe instead of a rule number
> for ipfw.
> Surely with dummynet(4) support into pf(4) too. I will polish the
> patch and post it later on.
>
>>>>
>>>> Thanks for sharing your very practical solution to a real world problem.
>>>>  Have a great weekend.
>>>
>>> If it could be rewritten as a netgaph node, maybe it could tag the
>>> classified packets, and tagging be compatible with both pf and ipfw (under
>>> discretionary user choice with configuration switchs), so both ipfw or pf
>>> could be used.
>>
>
> This means doing regex in kernel or just a daemon as mpd on top of netgraph?
>
>> I'll look into this when I have time.
>>>
>>> However a lot of work has to be done before. It works better on i386 than
>>> amd64 right now, wont compile on RELENG_6 without modifying some gcc tweaks,
>>> etc.
>>
>> Do you have a patch :-) ? Barring that, can you email me a copy of the build
>> output?
>>>
>>> I hope enhacing it can be a GSoC project in the future, or we (community)
>>> can raise some funds to make it happen faster. It is really a long-time
>>> needed feature to FreeBSD.
>>>
>>
>> Cheers.
>>
>> --
>> Mike Makonnen       | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc
>> mtm @ FreeBSD.Org   | AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
>> FreeBSD             | http://www.freebsd.org
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
>
>
> --
> Ermal
>



-- 
Ermal