OK then I will submit it as a patch in this weekend.
On Fri, May 9, 2014 at 1:11 AM, Chris H <[email protected]> wrote: > > On 5/8/14 15:38, Luigi Rizzo wrote: > >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: > >>> On 5/8/14 8:35, bycn82 wrote: > >>>> On 5/4/14 1:19, Luigi Rizzo wrote: > >>>>> > >>>>> > >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82<[email protected] > >>>>> <mailto:[email protected]>> wrote: > >>>>> > >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: > >>>>>> > >>>>>> > >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82<[email protected] > >>>>>> <mailto:[email protected]>> wrote: > >>>>>> > >>>>>> > >>>>>> [email protected]<mailto:[email protected]> > >>>>>> <mailto:[email protected]<mailto:[email protected]>> > >>>>>> > >>>>>> Thanks for your reply, and it is good to know the sysctl > >>>>>> for ICMP. > >>>>>> > >>>>>> finally it works.I just added a new `action` in firewall > and > >>>>>> it is called `pps`, that means it can be generic purpose > >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. > >>>>>> > >>>>>> the usage will be like below > >>>>>> > >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from > >>>>>> any to any* > >>>>>> 00100 pps 1 icmp from any to any > >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show > >>>>>> 00100 9 540 pps 1 icmp from any to any > >>>>>> 65535 13319 1958894 allow ip from any to any > >>>>>> root@F10:/usr/src/sbin/ipfw # > >>>>>> > >>>>>> > >>>>>> ???hi, > >>>>>> as julian said it would be great if you would like to share > your > >>>>>> code > >>>>>> so we can integrate it in future ipfw releases. > >>>>>> Once again citing Julian, dummynet is a bit of a superset of > pps but > >>>>>> not exactly, so i see value in the additional feature. > >>>>>> > >>>>>> One thing ???to keep in mind in the implementation: > >>>>>> > >>>>>> the burst size used for limiting is an important parameter that > >>>>>> everyone forgets. 1 pps is basically "don't bother me". > >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" > >>>>>> or "1 packet every ms" or (this is more difficult) > >>>>>> "20 pkt in the last 50ms interval". > >>>>>> > >>>>>> If i were to implement the feature i would add two parameters > >>>>>> (burst, I_max) with reasonable defaults and compute the > internal > >>>>>> interval and max_count as follows > >>>>>> if (burst> max_pps * I_max) > >>>>>> burst = max_pps * I_max; // make sure it is not too > large > >>>>>> else if (burst< max_pps / HZ) > >>>>>> burst = max_pps * HZ; // nor too small > >>>>>> max_count = max_pps / burst; > >>>>>> interval = HZ * burst / max_pps; > >>>>>> count = 0; // actual counter > >>>>>> > >>>>>> then add { max_count, interval, timestamp, count } to the rule > >>>>>> descriptor. > >>>>>> On incoming packets: > >>>>>> > >>>>>> if (ticks>= r->interval + r->timestamp) { > >>>>>> r->timestamp = r->ticks; > >>>>>> r->count = 1; > >>>>>> return ACCEPT; > >>>>>> } > >>>>>> if (r->count> r->max_count) > >>>>>> return DENY; > >>>>>> r->count++; > >>>>>> return ACCEPT; > >>>>>> > >>>>>> cheers > >>>>>> luigi > >>>>>> > >>>>> Hi Luigi, > >>>>> You are right, it will be more generic if provide two parameters > >>>>> as you described, > >>>>> But this PPS feature should not be used to control the traffic > >>>>> rate, the dummynet you provided is the correct way. > >>>>> So I am thinking in what kind of scenario, people need this PPS > >>>>> feature? > >>>>> in my opinion, people will use PPS only when they want to limit > >>>>> the connections/transactions numbers. ( already have limit > >>>>> command to limit the connections) > >>>>> So I think provide a simple PPS feature is good enough, and we > >>>>> can improve it if someone complaint on this. > >>>>> > >>>>> > >>>>> ???pps has a strong reason to exist because it is a lot cheaper > >>>>> than a dummynet pipe, and given its pur???pose is to police > >>>>> traffic (icmp, dns requests, etc) which should not even > >>>>> get close to the limit which is set, I think it is > >>>>> a completely reasonable feature to have. > >>>>> > >>>>> Given that the above code is the complete implementation > >>>>> with the two parameters (burst and interval) there is no > >>>>> reason not to use them, at least internally. > >>>>> > >>>>> Then you could choose not to expose them as part of the > >>>>> user interface (though since you are implementing a new > >>>>> option from scratch, it is completely trivial to > >>>>> parse 1, 2 or 3 arguments and set defaults for the others). > >>>>> > >>>>> cheers > >>>>> luigi > >>>> OK, PPS with 2 parameters , it is done, > >>>> But how to get the current time in millisecond? > >>>> any recommendation? > >>> In order to get the millisecond, i tried to include the timeb.h but i > >>> met below > >> FreeBSD has a global kernel variable called ticks which increments > >> (roughly) HZ times per second and is all you need for this > >> kind of coarse estimates. > >> In linux there is something similar (jiffies maybe ?), > >> and the code to build ipfw on linux does some reasonable > >> mapping. > >> > >> The code i posted is, i believe, complete and contains > >> all the details. > >> > >> cheers > >> luigi > >> > >>> n file included from > >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: > >>> @/sys/timeb.h:42:2: error: "this file includes<sys/timeb.h> which is > >>> deprecated" > >>> [-Werror,-W#warnings] > >>> #warning "this file includes<sys/timeb.h> which is deprecated" > >>> ^ > >>> any replacement for timeb.h > > > > Man page patch for PPS > > > > .It Cm pps Ar limit duration > > Rule with the > > .Cm pps > > keyword will allow the first > > .Ar limit > > packets in each > > .Ar duration > > milliseconds. > > > >- and it will be like blow > + and it will be below > > pps _limit duration_ > > Rule with the pps keyword will allow the first _limit > > _packets in > > each _duration _milliseconds. > > > > is that OK? > Just a suggestion. :) > > --Chris > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "[email protected]" > > > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[email protected]"
