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 presen
Hi Brett, Luigi, all,
> >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 transfor
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
> >
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
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
___
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 transfor
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
syntac
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
>
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
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 w
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
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)
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 op
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
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 t
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 peop
[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 configuration
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 p
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
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. T
20 matches
Mail list logo
