ipfw add skipto tablearg....

[Ian Smith]

On Tue, 19 Aug 2008, Luigi Rizzo wrote:
 > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote:
 > > On Thu, 31 Jul 2008, Julian Elischer wrote:
 > ...
 > >  > ipfw add 1000 skipto tablearg ip from any to table(31)
 > ...
 > >  > see attached patch... (hopefully not stripped)
 > >  > 
 > >  > Of course it is hoped that the rules you are skipping to are nearby
 > >  > as it iterates through the rules following the skipto to find the
 > >  > target,
 > > 
 > > Until $someone adds a direct skipto target jump at the virtual machine
 > > code level - big recalc hit when adding/deleting rules/sets I suppose -
 > > it's still the fastest way to get from a to b, where b > a
 > 
 > you mean with tables-based skipto targets ? Because the regular
 > skipto has been a constant-time op forever, even in ipfw1 i believe,
 > invalidating the target cache on a change and recomputing it the
 > fly at the first request.

Thanks; I'd completely missed the caching of skipto targets before, and 
it's all so well commented too.  blushing, but glad for the good news.

But yes I was pondering Julian's patch, which has to lookup_next_rule 
every time, and also Mike's bending of divert reentry rule number in 
ipfw-classifyd with similar intent, which also has to hunt forward in 
linear time for its target rule - or am I missing something else here?

 > > Speaking of which, should ipfw whinge when asked to skip backwards,
 > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd
 > > and a local test months ago.
 > 
 > right... but the error can only be reliably detected in the kernel,
 > as the rule number is not always known when the rule is added.

Yes I meant at run-time.  On second thoughts, it'd be too easy a way to 
spam syslogd in the general case, but maybe reporting target < current 
rule for such dynamic forms of skipto might highlight config errors?

I should STFU and resume lurking unless I can contribute code, I know.

cheers, Ian