Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Synopsis: [ipfw] [patch] ipfw small patch - new RULE OPTION State-Changed-From-To: suspended-closed State-Changed-By: ae State-Changed-When: Mon Dec 13 11:15:21 UTC 2010 State-Changed-Why: It is my PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Paolo Pisati wrote: add packet counter as well. That's all possible with one opcode, though... if anyone post an updated patch, i'll commit it. Hi, Paolo. Any progress in this? I updated patch: http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Hi Andrey V. Elsukov!
On Tue, 18 Mar 2008 10:43:31 +0300; Andrey V. Elsukov wrote about 'Re:
kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION':
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.
I think this should be done - limit of 4G bytes is still useful for many
users (and 4G packets even more), and others could wait until table argument
will be extended to u64, which will break ABI
2. dynamic rules: i think it should be implemented as extension
to current O_LIMIT opcode or something similar.
No, not there. Dynamic rules should be massively redone, with some other
things, I'll write a big proposal (possibly a SoC candidate) in a day or two.
What I'm trying to propose is generality - it allows more users to do
different things, and if you do something specific, you're limiting some of
them. For example, how do you propose toi change dynamic rules like O_LIMIT ?
I suppose that will allow only one action per dynamic rule only, not telling
about the ABI.
And what I am proposing is a using several checks: remember that
dynamic rule in fact jumps to action part of parent rule, which can be skipto.
Imagine a server with two interfaces to different providers, which must route
replies to requests to appropriate interface. In pf you would specify reply-to
and nothing more, but in ipfw you can make a whole block of checks for each
dynamic rule! Then, plain emulation of reply-to looks like this:
ipfw add 1 check-state
# ...some checks for outgoing and incoming firewalling here
ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 } # reqs from outside
ipfw add 400 allow in recv $int_if # answers on internal pass
ipfw add 500 fwd $gw1 tagged 1 # the only left are answers on ext iface,
ipfw add 600 fwd $gw2 tagged 2 # send them to appropriate gateway
Here every matched dynamic rule will jump to rule 300, and will be checked till
rule 600. Now, assume that you want to limit bandwidth for long-playing
downloads from your server? So you simply insert a pipe rule to that block:
ipfw add 450 pipe 1 not counterlimit dyn-bytes 1000K
and all outgoing short-lived connections will be unaffected, and those
downloaded more than about 1 meg will be shaped.
It is useful not only for shaping, but, for example, when you are sending
packets to netgraph for L7 check with ng_bpf+ng_tag and know that check is
expensive and you are interested only in first packets of connection, others
are meaningless.
So, that dynamic rule checking is assumed to be plain q = lookup_dyn_rule(...);
if (q-bcnt) ...
Also i have question about my current implementation. Does it
needed to have ability of humanized printing of limits, which
was implemented before?
It could be desirable to think about global ipfw option to print humanized
values not only in this option, but several others too. Just like hostnames,
IP addresses in tableargs, etc.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Hi Andrey V. Elsukov! On Tue, 18 Mar 2008 11:48:15 +0300; Andrey V. Elsukov wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': 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 Yes, i agree. As I remember, we already talked about this some time ago. Can you please recall what else you've discussed? :) -- WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED] [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Vadim Goncharov wrote: Hi Julian Elischer! On Tue, 18 Mar 2008 01:09:19 -0700; Julian Elischer wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': 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.. Are you talking about tablearg-values (data), or keys too? And does that count only IP addrs and integers of different sizes, or strings too? In this case I'm talking about the args. table keys DO need to be expanded to handle ipv6 stuff and other such things, but that is not what we were discussing. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Paolo Pisati wrote: On Thu, Mar 13, 2008 at 09:21:11AM +, 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. 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? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Andrey V. Elsukov wrote: Paolo Pisati wrote: On Thu, Mar 13, 2008 at 09:21:11AM +, 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? ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Julian Elischer wrote: 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.. Yes, i agree. As I remember, we already talked about this some time ago. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Synopsis: [ipfw] [patch] ipfw small patch - new RULE OPTION State-Changed-From-To: open-suspended State-Changed-By: vwe State-Changed-When: Wed Mar 12 20:58:32 UTC 2008 State-Changed-Why: Awaiting maintainer interest. This may be useful for one, so we're not just closing this silently. http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
The following reply was made to PR kern/80642; it has been noted by GNATS. From: Andrey V. Elsukov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION Date: Tue, 27 Jun 2006 16:39:21 +0400 I think this PR can be closed. I don't see any interest in him among committers. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
