From owner-freebsd-hackers  Thu Jul 10 16:32:21 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id QAA04711
          for hackers-outgoing; Thu, 10 Jul 1997 16:32:21 -0700 (PDT)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA04704
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 10 Jul 1997 16:32:13 -0700 (PDT)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA09364; Thu, 10 Jul 1997 16:30:13 -0700 (PDT)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma009352; Thu Jul 10 16:29:50 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id QAA04387; Thu, 10 Jul 1997 16:29:50 -0700 (PDT)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <199707102329.QAA04387@bubba.whistle.com>
Subject: Re: ipfw rules processing order when DIVERTing
In-Reply-To: <33C5690F.2C67412E@whistle.com> from Julian Elischer at "Jul 10, 97 03:58:23 pm"
To: julian@whistle.com (Julian Elischer)
Date: Thu, 10 Jul 1997 16:29:50 -0700 (PDT)
Cc: archie@whistle.com, owensc@enc.edu, freebsd-hackers@FreeBSD.ORG,
        ari.suutari@ps.carel.fi
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> > > This is somewhat counter-intuitive to me.  If this how it works, what is
> > > the reason for this design, since, as I think about it, there must be a
> > > performance penalty to this approach (multiple passes of rules).  I had
> > 
> > There are two reasons for this...
> > 
> > 1. The new packet (post-diversion) may be different from the old packet
> >    (pre-diversion), so it should be checked again to insure that it
> >    doesn't avoid any rules that apply to it.
> > 
> > 2. It's a lot easier to code this way :-)
> > 
> Just to be devil's advocate,  ;-)
> I think it could start processing at the next higher number
> after the one it was diverted from..
> in other words it could have an implicit 'skipto  (N+1)' rule
> 
> the 'divert' word to me suggests that it should come back to the same
> place it left from. :)

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?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com