From owner-freebsd-current  Fri Aug 23 09:48:27 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA09698
          for current-outgoing; Fri, 23 Aug 1996 09:48:27 -0700 (PDT)
Received: from red.jnx.com (ppp-206-170-2-37.sntc01.pacbell.net [206.170.2.37])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA09687;
          Fri, 23 Aug 1996 09:48:19 -0700 (PDT)
Received: from base.jnx.com (base.jnx.com [208.197.169.238]) by red.jnx.com (8.7.5/8.7.3) with ESMTP id JAA17346; Fri, 23 Aug 1996 09:48:16 -0700 (PDT)
Received: from base.jnx.com (localhost.jnx.com [127.0.0.1]) by base.jnx.com (8.7.5/8.7.3) with ESMTP id JAA15997; Fri, 23 Aug 1996 09:48:04 -0700 (PDT)
Message-Id: <199608231648.JAA15997@base.jnx.com>
To: sos@freebsd.org
cc: rgrimes@GndRsh.aac.dev.com, archie@whistle.com, julian@whistle.com,
        current@freebsd.org
Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c 
In-reply-to: Your message of "Fri, 23 Aug 1996 08:41:51 +0200."
             <199608230641.IAA17001@ra.dkuug.dk> 
Date: Fri, 23 Aug 1996 09:48:04 -0700
From: Paul Traina <pst@jnx.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I've got the reassembly code properly modularized (did it last night), so it
can be called anywhere along the forwarding path and do the right thing.

By not agressive enough, I mean I think you have the right idea, but the
syntax
for the hook should be something like:

	for (hook = iphooks.ipinput.lh_first; hook; hook = hook->next) {
		if (!(*hook)(IP_INPUT, &m, &ip))
			break;
	}

Basicly, we make a linked list of hooks and call them in order until one of
them swallows the packet or they're all complete.

We do this for ip input processing, ip output processing, and perhaps as
suggested, in the IP raw input (packet received) processing section of the code.

Then, if you want IP filtering, just add the hook to the generic "registry"

Paul

  From: sos@freebsd.org
  Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c
  In reply to Paul Traina who wrote:
  > 
  > 
  >   I like the direction that sos layed out, now it just needs to be expanded
  >   so that the pointed to object can either be in the kernel or in user land
>>.
  > 
  > I do too, however I think it's not agressive or generic enough in the face
  > of the mess from the divert code.
  
  Sorry I've been asleep while this thread has gone into some real nice
  discussion !! (I dont get why we didn't get to that sentiment when I
  brought it up last time :( Oh, well....)
  
  I'm not sure I understand what you mean by agressive enough ??
  
  I still think that it should be as simple as possible, but of cause
  also generic enough to be usefull.
  
  > I just started hacking around on things (just scratch copies of the files),
  > and I think we could get a very clean and general API along the way of what
  > I discussed earlier that should handle all four functions just fine with on
>>e
  > function call API (divert/nat/firewall/accounting).
  
  Remember that there allso should be a hook into the sockopt
  processing loop in raw_ip.c, so that it is possible to intall
  new options...
  
  I have the code (somewhere) that does what I envisioned, just its for 
  the code in ip_* as before the divert crap got in. 
  I spent some time designing this as I think this interface into the 
  IP stream is pretty important..
  
  I have a project that also relies on this to work, but I have no
  reservations on changing it RIGHT NOW, so I can get in peace
  with myself again :)
  
  
  
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Soren Schmidt             (sos@FreeBSD.org)             FreeBSD Core Team
                 So much code to hack -- so little time.