On Mon, Sep 19, 2005 at 09:11:33AM -0600, Brett Glass wrote:
I don't see it that way, because low level languages like assembler
are normally very efficient and highly granular. The underlying
opcode language of IPFW is low level for sure. But I would classify
IPFW's language, as presented
[see long original request below]
Bret, you want a block structured ipfw control language, but
ipfw is an assembly language. You have to live with that.
Your only way out is
A. write a translator from high level to low level language
(many people do use sh scripts to generate ipfw
At 12:56 AM 9/19/2005, Luigi Rizzo wrote:
[see long original request below]
Bret, you want a block structured ipfw control language, but
ipfw is an assembly language. You have to live with that.
Your only way out is
A. write a translator from high level to low level language
(many people do
On Mon, Sep 19, 2005 at 01:32:33AM -0600, Brett Glass wrote:
...
Unfortunately, this requires inverting the sense of rules. And in IPFW's
very simplistic language, you can't invert a single rule with more
than one condition into another single rule because you can only
yes i know. you need to
Brett Glass wrote this message on Mon, Sep 19, 2005 at 01:32 -0600:
At 12:56 AM 9/19/2005, Luigi Rizzo wrote:
[see long original request below]
Bret, you want a block structured ipfw control language, but
ipfw is an assembly language. You have to live with that.
Your only way out is
A.
At 01:59 AM 9/19/2005, Luigi Rizzo wrote:
Same for as the 'resume' option. It might be nice to have,
however but there is already a two-rule version (the one i
suggested, follow the non-terminating action with a skipto rule)
so its absence is not blocking you from doing what you want.
That
On Mon, Sep 19, 2005 at 09:11:33AM -0600, Brett Glass wrote:
At 01:59 AM 9/19/2005, Luigi Rizzo wrote:
Same for as the 'resume' option. It might be nice to have,
however but there is already a two-rule version (the one i
suggested, follow the non-terminating action with a skipto rule)
so
At 03:40 AM 9/19/2005, John-Mark Gurney wrote:
What's awkward about:
#define PIPE_FOO 1
#define PIPE_BAR 2
add pipe PIPE_FOO config bw 64kbit/sec
/* ... etc ... */
I've done that, and unfortunately it does not solve the problem
I'm describing.
The awkward and inefficient part comes when you
At 09:16 AM 9/19/2005, Luigi Rizzo wrote:
Same for as the 'resume' option. It might be nice to have,
however but there is already a two-rule version (the one i
suggested, follow the non-terminating action with a skipto rule)
so its absence is not blocking you from doing what you want.
Luigi, Brett,
in terms of implementation, if you want to add it, the best place
would be to add the 'skipto' fields to each 'action' opcode.
I am not very interested in implementing it, though, because i still see
ipfw as a low-level language.
Is it a goal or an observation ?
I don't see
On Mon, Sep 19, 2005 at 06:08:53PM +0200, Jeremie Le Hen wrote:
Luigi, Brett,
in terms of implementation, if you want to add it, the best place
would be to add the 'skipto' fields to each 'action' opcode.
I am not very interested in implementing it, though, because i still see
ipfw as a
At 10:08 AM 9/19/2005, Jeremie Le Hen wrote:
OTOH, I agree with Luigi about the resume keyword. This introduces
a kind of linked-lists, but this is just syntactic sugar and I can't
see any performance improvement with this.
I think that a few examples might show why it'd be more than
syntactic
At 10:20 AM 9/19/2005, Luigi Rizzo wrote:
original
ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN
negated:
ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN
ipfw add 1000 dosomething
This doesn't work, because you must transform cond1
Oops! In my earlier message, I said:
This doesn't work, because you must transform cond1 cond2 cond3...
into multiple rules that implement ~(cond1 || cond2 || cond3...).
I should have said that you must implement !(!cond1 || !cond2 || !cond3...).
--Brett
Brett Glass wrote this message on Mon, Sep 19, 2005 at 09:32 -0600:
At 03:40 AM 9/19/2005, John-Mark Gurney wrote:
What's awkward about:
#define PIPE_FOO 1
#define PIPE_BAR 2
add pipe PIPE_FOO config bw 64kbit/sec
/* ... etc ... */
I've done that, and unfortunately it does not solve
On Mon, 19 Sep 2005, Brett Glass wrote:
At 10:20 AM 9/19/2005, Luigi Rizzo wrote:
original
ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN
negated:
ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN
ipfw add 1000
For years, we've used Dummynet in FreeBSD for bandwidth control.
Unfortunately, the semantics of IPFW can, at times, make the use of
Dummynet awkward and inefficient. For example, suppose you want to
create a set of rules that does bandwidth limiting first
and then blocks certain ports (e.g.
skipto
man ipfw - e.g. ipfw add 10 skipto 4000 all from any to any layer2 out
Brett Glass writes:
For years, we've used Dummynet in FreeBSD for bandwidth control.
Unfortunately, the semantics of IPFW can, at times, make the use of
Dummynet awkward and inefficient. For example, suppose
At 09:24 PM 9/18/2005, Dave+Seddon wrote:
skipto
man ipfw - e.g. ipfw add 10 skipto 4000 all from any to any layer2 out
It's not that simple. Each rule that can send packets into a pipe
has at least two conditions (e.g. IP address, interface name, and
in or out via that interface). Do you
19 matches
Mail list logo
