Date: Fri, 23 Aug 1996 09:07:40 +0200 (MET DST) From: sos@freebsd.org To: pst@jnx.com (Paul Traina) Cc: archie@whistle.com, julian@whistle.com, sos@freebsd.org, rgrimes@gndrsh.aac.dev.com, current@freebsd.org Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c Message-ID: <199608230707.JAA17128@ra.dkuug.dk> In-Reply-To: <199608222310.QAA08618@base.jnx.com> from "Paul Traina" at Aug 22, 96 04:10:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608230707.JAA17128>