Date: Fri, 23 Aug 1996 15:56:04 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Julian Elischer <julian@whistle.com> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/netinet in.h ip_fw.h ip_input.c ip_output.c Message-ID: <v02140b02ae43c630554a@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
>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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b02ae43c630554a>