Denis,

> As described, you have an ACTIVE PROCESS running on the
> R-Pi. Since the TCP/IP interface uses source IP:port/destination
> IP:port (where destination is the R-Pi) to define a connection, your
> active process will have to maintain a table mapping the source:R-Pi
> connections to R-Pi:other-destination. That is what a NAT router is
> performing!

Either you are describing that as something special when every other 'puter
does the same, or you have read something I've never said.

But to make it absolutily clear, in my explanation the RPi is *passive*.  It
waits for connections initiated by both hosts, and only than tries to / can
write received packets to the other interface.

> If you are trying to sanitize the data "dropping IP/port" you are
> now looking at the aforementioned "data diode" operation

Nope.   Both sides can send and both sides can receive.  The only thing that
happens in the RPi is that the connection gets scrubbed (notice: the
connection, not its data).

> Your original post implied the R-Pi would be a more passive device.

As in the above, it is supposed to be.

> One side would dump a file
....
> At some later time the other side would retrieve the file from
> the R-Pi.

Why is it that "passive" also must mean "time delay" and (thus?) "files" ?
I don't get it.

> THAT form of operation is easily done using FTP (deprecated in
> the wild as the log-on information is sent in the clear)

as well as for its multi-port usage ofcourse, which doesn't work well with
(simple) firewalls.

But as mentioned, I had something /much/ simpler in mind - with the RPi
being next to invisible.

Doesn't mean that I cannot also think of setting the RPi up as a
multi-subnet data-storage device ofcourse.  Heck, I might even think of
setting up both !

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05