Date: Tue, 18 Mar 2008 01:09:19 -0700 From: Julian Elischer <julian@elischer.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Vadim Goncharov <vadim_nuclight@mail.ru>, freebsd-ipfw@FreeBSD.org Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION Message-ID: <47DF78AF.400@elischer.org> In-Reply-To: <47DF72A3.4030502@yandex.ru> References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <slrnfthsg7.dgk.vadim_nuclight@hostel.avtf.net> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey V. Elsukov wrote: > Paolo Pisati wrote: >> On Thu, Mar 13, 2008 at 09:21:11AM +0000, Vadim Goncharov wrote: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 >>> Yes, this is useful, but some minor changes are needed, I think. >>> First, rename >>> it to "bytelimit" or somewhat. Second, allow this to use tablearg and >>> possibly >>> ability to reference a counter to corresponding dynamic rule, to >>> allow this to >>> act for a specific IP or connection without need to write many rules. >>> Third, >>> add packet counter as well. That's all possible with one opcode, >>> though... >> >> if anyone post an updated patch, i'll commit it. > > So, updated patch is here: > http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff > > Now this option divided into two "counterlimit-bytes" and > "counterlimit-packets". > Rules example: > add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \ > in recv external_if > add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \ > in recv external_if > > About Vadim's prepositions: > 1. tablearg: it's possible, but now we use u32 argument in > tables, but counterlimits are 64-bits values. First of we > should extend our current table argument to 64 bit. tables should be expanded to have different types of values.. 32 but ints IP addresses (currently I'm overlaying it on 32 bit ints) IPV6 addresses. skipto locations byte limits.. > > 2. dynamic rules: i think it should be implemented as extension > to current O_LIMIT opcode or something similar. > > Also i have question about my current implementation. Does it > needed to have ability of "humanized" printing of limits, which > was implemented before? >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DF78AF.400>