Using an RPi 3B+ as a "post office" between two subnets ?

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

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.

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

On Sun, 28 Jun 2020 23:39:49 -0600, Grant Taylor declaimed the following:

Except, from your examples, the source is still requesting a route to the final destination -- which the OP seems insistent is not viable for him. He wants both sides to only address the R-Pi in the middle, and they must each initiate the connection /to/ the R-Pi.

Which, even with UUCP, comes down to the source connecting/passing the data to the R-Pi only, and the destination also using UUCP for connecting/fetching the data from the R-Pi. So... again we have the R-Pi as a file drop/mail box and UUCP/NFS/(s)FTP are essentially equivalent in functionality. Files are transferred into some storage on the R-Pi -- there is no real time packet transfer from one machine to the other (and especially no ad-hoc protocols).

What the OP wants is almost the reverse of a VPN where both sides are treated as part of the same local/private network, with connections tunneled through the unsecured public network to a VPN server.

That's a pretty good description good - now read Stevens book on unix networking programming (other books are available) and write your program!

I can't see what's stopping you.

Sometimes I think you enjoy more discussion instead of actually googling around/reading and getting the job done.

There's a newsgroup for unix programming where are more specific questions can be asked.

And before you say anything - in this context "unix" = "linux".

~chuckle~

"in this context"

I wouldn't argue with that even if I could. ;-)

I think we are in agreement.

Though I think we have different understandings of what's going on.

Both A and C initiate a connection to the R-Pi (B). UUCP transfers the files on our behalf. It uses a directory structure with multiple sub-directories as queues for the destination system. Both A and C pull files from B if there are any queued for them.

I think what is and is not acceptable to the OP is somewhat of a quagmire and difficult to say with any degree of certainty. I think there are two things that the OP would like, and they are somewhat at odds with each other, at least in how they achieve a common overarching goal.

The only thing that I think UUCP falls short on is the fact that A and C know that they are talking to the other and that it is by way of B. But, based on my current understanding of the OP's desires, I don't think this is really a /problem/ so much as it is a strong /desire/.

I honestly believe that UUCP does bring much in the form of a solution. I wouldn't have suggested it if I didn't think so.

One big leg up that UUCP has is that it is an established mechanism for dealing with this, retrying, multiple systems, and does not require any form of solutioning. Others at the very least require defining and managing a queue structure. I also question how well things will deal with the R-Pi (B) NAS being unavailable when they want to push new files or poll for / pull queued files.

Sort of. But much more restrictive. And without relying on a firewall to impose that restriction.

There is a loadable module accept: accept [-t timeout] [-v varname] [-r addrvar ] port Accept a network connection on a specified port. This builtin allows a bash script to act as a TCP/IP server.

Options, if supplied, have the following meanings: -t timeout wait TIMEOUT seconds for a connection. TIMEOUT may be a decimal number including a fractional portion -v varname store the numeric file descriptor of the connected socket into VARNAME. The default VARNAME is ACCEPT_FD -r rhost store the IP address of the remote host into the shell variable RHOST, in dotted-decimal notation

If successful, the shell variable ACCEPT_FD, or the variable named by the -v option, will be set to the fd of the connected socket, suitable for use as 'read -u$ACCEPT_FD'. RHOST, if supplied, will hold the IP address of the remote client. The return status is 0.

On failure, the return status is 1 and ACCEPT_FD (or VARNAME) and RHOST, if supplied, will be unset.

The server socket fd will be closed before accept returns.

Could this be what you're looking for? Implementation is left as an exercise for the reader. I can't find any info about it on the web (cursory look).

Didn't know about that. accept() is also a linux system call, see man accept.

man 2 accept man accept gets me cupsaccept out of man section 8 (slackware)

If they specify 802.1Q VLAN they do interwork.

Oh, right. Worked for me on Raspbian ("RaspiOS"?) but I don't have cups installed. And yes it's in 2:

pi@dev:~ $ man -k accept accept (2) - accept a connection on a socket accept4 (2) - accept a connection on a socket Log::Dispatch::Null (3pm) - Object that accepts messages and does nothing signalfd (2) - create a file descriptor for accepting signals signalfd4 (2) - create a file descriptor for accepting signals xdr_accepted_reply (3) - library routines for remote procedure calls XtCallAcceptFocus (3) - calla widget's accept_focus procedure

That sounds like a message queue, have a look at mosquitto / mqtt. It supports all kinds of restrictions (e.g. users can only access certain topics, client certificates). An MQTT broker can have multiple listeners on multi-homed systems like you envision B to be.

A publishes a datagram to the broker running at B, C subscribes to A's topic and receives it when there is one. And the other way around. It is store-and-forward by nature, A and C can be online at the same time, but they don't have to be.

Use iptables to only allow mqtt ports, and/or to restrict the source and destination networks.