On Mon, 29 Jun 2020 10:14:09 +0200, "R.Wieser" 
declaimed the following:

>
>Not quite.   My basic idea was/is to have the Pi to respond to a connect
>request on a single port only, and than, when both sides have connected
>(their actions, not the Pi's), transfer datapackets from one interface
>(socket) to the other.
>

 Which implies you have defined a protocol and CLIENT programs running
on the "sides" to talk to that port. The R-Pi is listening for connections
-- making it a /server/ application. The "sides" need to have client
applications that ask for that port. Client programs that use other ports
won't connect -- so you can't use the R-Pi to, say, tunnel TELNET from one
"side" to the other "side" as TELNET uses port 23 as the server side.

https://www.man7.org/linux/man-pages/man2/listen.2.html
https://www.man7.org/linux/man-pages/man2/accept.2.html

 The R-Pi would have to be listening for any connection requests on the
known port -- but likely from any interface. You then accept that
connection which creates a new socket with R-Pi and "other" end-points. You
also need to multi-thread passing that new socket off so the main server
can go back and process the next listen/accept sequence. But now you have
two sockets (and if you are listening on "any" interface, both accepts
could be to the same "other", just with different end-point port numbers).
How you identify that these two accepted sockets are supposed to be
forwarding packet data between each is something you will have to write.

 The whole TCP/IP system is based around one (client) side initiating
connections all the way through to the remote (server) side (and servers
that spawn threads for each connection in order to allow them to go back
and accept more connections)..


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

--- SoupGate-Win32 v1.05