On Sun, 28 Jun 2020 22:10:33 +0200, "R.Wieser" 
declaimed the following:

>
>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.

 Which is an active process -- somehow you need to implement a protocol
in which one side can say "I want to transfer data to other side" AND the
other side has to say "I want to receive data from the first side"...
Somehow you will have to be able to specify the identification of this
channel AND you will have to maintain the address translation table (source
IP/Port  destination IP/Port) for these packets. BUT, unlike a NAT
router, you don't want the router part to initiate the gateway operation
(in a router, your computer says "I want to connect to some external mode",
the router takes the information (IP/Port) of the destination, swaps out
the source IP/Port replacing it with a router NAT IP/Port (ie; the
external/ISP assigned IP address, and some unused port on the router), and
updates the NAT table. The external device then sends ACKs and return data
(if any) to the IP/port the router gave it, the router than replaces its
IP/port with the internal device IP/port (per the NAT table).

 The external host never sees the IP/port of the internal host, only the
IP/port given by the middleman router.

 "Post office"/"mailbox" systems rely on buffering sent traffic locally,
until the recipient connects and takes the stuff out of the mailbox.

 I know of nothing that does gateway type operations but only when both
external sides have issued a connection request to the middleware. You're
going to have define the full protocol of this middleware, along with
client software running on the external nodes to initiate the connections
and handle transfer and error conditions. You will NOT have just ad-hoc
(eg: any TCP/IP protocol) to go from one node to another.

>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).
>

 NAT router... Not just a gateway (gateways don't mask IP addresses,
they just forward stuff coming in on one interface that is not addressed to
the local machine through to the next specified interface).

 A NAT router does the IP/Port substitution, but has to maintain the
status of active connections, error retries, etc. (Note that the NAT
affects the "outgoing" side of the middle -- the source side still has to
know the IP of the destination.

 What you do NOT get is the concept that both sides connect to the
middle and negotiate a connection. For that you are going to have to create
a custom NAT system in which SOME type of packet says "I want to connect to
some service port of some named device" [using "names" without using DNS
name->IP lookups]. I say "service port" as typically the source will be
asking to connect to a server running on a known port number... The source
client, however, normally uses an "random" port number -- which complicates
matters as the other side can't say "connect to port-X of other named
device.




--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05