Date: Thu, 22 Aug 1996 16:10:22 -0700 From: Paul Traina <pst@jnx.com> To: Archie Cobbs <archie@whistle.com> Cc: julian@whistle.com (Julian Elischer), 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: <199608222310.QAA08618@base.jnx.com> In-Reply-To: Your message of "Thu, 22 Aug 1996 15:38:52 PDT." <199608222238.PAA10234@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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()). The second thing is that there should not be separate hooks for the firewall vs the NAT code. 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. 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. 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). This seems much cleaner to me and gets most of the ugly DIVERT crap out of ipinput.c Paul From: Archie Cobbs <archie@whistle.com> Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c > > In reply to Rodney W. Grimes who wrote: > > > > context switches are just not going to cut it... > though sometimes you need to do things with packets that > require interaction with a database of reading from files etc.. > I put it to you that having a general way of getting the packets > out of the kernel is better than adding bloat IN the kernel to > do these things. No reason we can't have both; then everybody's happy :-) 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. User mode is also good for testing & debugging new things. -Archie ___________________________________________________________________________ Archie L. Cobbs, archie@whistle.com * Whistle Communications Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608222310.QAA08618>