From owner-freebsd-hackers  Sun Jul 13 18:26:24 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA19042
          for hackers-outgoing; Sun, 13 Jul 1997 18:26:24 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19034
          for <freebsd-hackers@FreeBSD.ORG>; Sun, 13 Jul 1997 18:26:20 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id SAA13945;
	Sun, 13 Jul 1997 18:26:55 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd013942; Mon Jul 14 01:26:46 1997
Message-ID: <33C97FBE.41C67EA6@whistle.com>
Date: Sun, 13 Jul 1997 18:24:14 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Darren Reed <avalon@coombs.anu.edu.au>
CC: Archie Cobbs <archie@whistle.com>, owensc@enc.edu,
        freebsd-hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi
Subject: Re: ipfw rules processing order when DIVERTing
References: <199707130852.BAA26310@gatekeeper.whistle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Darren Reed wrote:
> 
> In some mail from Archie Cobbs, sie said:
> > Yes! ``It could start processing at the next higher number.''
> > I agree with that :-)
> >
> > The problem is that when the packet returns to the kernel from
> > user-land, that bit of state that says "this packet has already
> > seen rules 1-2000 (or whatever)" is lost, and you can't retrieve
> > it. The only way to do this would be for the user-land process
> > to send back some additional info that says "skip to rule 2000".
> >
> > Doable, but .. not very pretty?
> 
> what if the packet is changed enough to make the outcome of starting at
> N+1 different to starting at 1 ?


As I said earlier, this is the main argument FOR keeping it as it is...
the new semantic however would allow this decision to be taken
by the diverting program.
If it feeds it back with the received line number processing carries
on where it left off.
if it sets it to 0 processing restarts at the beginning...

it would be easier to set up "cascades" of processes
where you could chain theoutput of one to another..
I'd also like to see the 'only forwards' rule with 'skipto'
removed..
and some sort of 'subroutine' capability.
:)



julian