From owner-freebsd-current  Fri Aug 23 00:07:52 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id AAA02718
          for current-outgoing; Fri, 23 Aug 1996 00:07:52 -0700 (PDT)
Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA02713;
          Fri, 23 Aug 1996 00:07:48 -0700 (PDT)
Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id JAA17128; Fri, 23 Aug 1996 09:07:40 +0200
Message-Id: <199608230707.JAA17128@ra.dkuug.dk>
Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c
To: pst@jnx.com (Paul Traina)
Date: Fri, 23 Aug 1996 09:07:40 +0200 (MET DST)
Cc: archie@whistle.com, julian@whistle.com, sos@freebsd.org,
        rgrimes@gndrsh.aac.dev.com, current@freebsd.org
In-Reply-To: <199608222310.QAA08618@base.jnx.com> from "Paul Traina" at Aug 22, 96 04:10:22 pm
From: sos@freebsd.org
Reply-to: sos@freebsd.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In reply to Paul Traina who wrote:
> 
> Whoops, I see that's exactly what it already kind-of does.
> 
> I see two things that need to be done.
> 
> First off, the fragment diversion code has got to be re-engineered.  The
> current state is totally disgusting.  That may mean that the divert code
> inside IPFW actually retains state and does fragmentation reassembly itself
> (by calling ip_reass()).

Exactly, I do this allready in my NAT code...

> The second thing is that there should not be separate hooks for the firewall
> vs the NAT code.

Exactly, thats why I propose a single function vector, that evtually
can be chained for fw, nat, crypt whatever...

> Luckily the two may be able to be solved with the same idea.
> 
> There should be one hook, and one hook only, and that hook can either
> return a mbuf chain, which means continue processing this mbuf chain,
> or null, which means I've taken care of everything, just clean up your
> accounting.

YES !

> The NAT code is going to need to do fragmentation reassembly for simplicity
> sake, and the divert code apparently wants to do so too,  so both of them
> should be responsible for handling fragments.

YES !

> That means, if you get a fragment in, if it's a frag you may be interested
> in (due to info in the IP header), you do all the standard reassembly.
> If the reassembly code swallows the fragment (don't have all bits), just
> return NULL, you're done.  If the reassembly code returns with a fully
> reassembled packet, /then/ you do your divert or NAT operation on the
> entire packet.
> 
> If you're not interested in reassembly, you just go on your merry way and
> return the fragment.
> 
> The "diversion/firewall/accounting/nat" code should basicly consist of a
> linked list of these data/control routines, and you just run through the
> entire linked list, taking the output from one operation and feeding it
> into the input of the next (assuming no-one swallowed the packet).

Sure, but why not stay whith the much simple function vector, it also
allows for much smaller overhead.

> This seems much cleaner to me and gets most of the ugly DIVERT crap out
> of ipinput.c

YES YES !!
  
>   I like Soren's "pointer chaining" idea .. as long as divert sockets
>   are retained. Then you can use the kernel to do something if it
>   is suitable (and/or you need performance), or if not, then you can
>   always do it in user mode.

I have no problem with retaing the divert type sockets in the
system, why not make them generically there ??

>   User mode is also good for testing & debugging new things.

Naw, REAL kernel hackers use LKM's and printf's :)


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt             (sos@FreeBSD.org)             FreeBSD Core Team
               So much code to hack -- so little time.