From owner-freebsd-current Fri Aug 23 13:56:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11523 for current-outgoing; Fri, 23 Aug 1996 13:56:27 -0700 (PDT) Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA11514 for ; Fri, 23 Aug 1996 13:56:21 -0700 (PDT) Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id PAA00145; Fri, 23 Aug 1996 15:56:00 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 1996 15:56:04 -0500 To: Julian Elischer From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Terry Lambert wrote: >> >> > 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; >> > } > >how can you order them? >say, I want encrypted NAT.. I need to do the NAT first, because NAT >peaks inside the packets for hints on ftp transfers etc. Rather than try to pile the processes on a single stack, why don't we pass the results from one handler to the next? Thus for your example, a program would write to the "encrypted NAT" device. That device would look inside and massage the data to generate a message ready for the "encrypted IP" device. In turn, the "encrypted IP" device would may things ready for the "IP" device which might then go through the "IP ROUTER" and be assigned to an "IP over PPP" handler. Eventually, the data would go out over some serial port and the message buffers would be released. In most cases, the output of a pseudo-device would be directly linked to the input of another handler. Naturally, each of these handlers would use the common inter-handler protocol which is probably different from the external representation.