Date: Fri, 23 Aug 1996 09:48:04 -0700 From: Paul Traina <pst@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 Message-ID: <199608231648.JAA15997@base.jnx.com> In-Reply-To: Your message of "Fri, 23 Aug 1996 08:41:51 %2B0200." <199608230641.IAA17001@ra.dkuug.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608231648.JAA15997>