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 <[EMAIL PROTECTED]> wrote: > On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen <[EMAIL PROTECTED]> wrote: >> Patrick Tracanelli wrote: >>> >>> eculp escreveu: >>>> >>>> Quoting Mike Makonnen <[EMAIL PROTECTED]>: >>>> >>>>> 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" >> > > > > -- > Ermal > -- Ermal _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"