:) no problemo. 
It is going to go through a major rewrite after the paper goes out, 
but once thats done it shoudl work better, faster, and have fewer 
idiosyncracies. plain old forwarding is its default behavior (it puts the 
ethernet frames on the other side of the box back onto the wire with the 
original ehternet headers, so you see the original source's mac address in
the packet, for example, arps work through it, etc) .. ill post about it 
once it is done.

On Tue, 14 May 2002, Matthew Mondor wrote:

> On Tue, 14 May 2002 10:16:32 -0400 (EDT)
> Lord Isildur <mrfusion@uranium.vaxpower.org> wrote:
> 
> > side and come out the other, and without some out of band communication, 
> > neither side of the traffic can tell (unless its doing some very smart 
> > things with a lot of guessing and statistics) that its being diddled with
> > in the middle.
> 
> That would probably be perfect, all that is really needed to port my code
> is that the IP address be re-written so that logs (and ftpd data port) on
> the internal machine the connections are forwarded to be fooled with the
> actual client's address... and of course that forwarded port must not be
> fixed, the userspace daemons should decide where and when to connect.
> 
> Thanks, not that this is required right now, it can wait, I however was
> wondering about the possibilities of such thing under netbsd, which has
> lately become my favorite system... Most of my code ported easily but this
> one requires kernel-dependant capabilities...
> 
> Matt
>