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

Thought so. In that case you need to add a second ethernet to the Pi - a good USB-2 ethernet should get you 100Mb/s, connect one to each of the networks and arrange for NFS or Samba to export shares to both networks.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 

Chris,

It is.

You are already a few steps to far ahead for me I'm afraid.

Although I know a thing or two about TCP/IP and UDP conections on Windows, I'm a rather newbie in regard to Linux and the RPi. As such I have no idea how to add and deal with an another ethernet interface, like how to keep it seperate from the one already present.

That is also why I asked if a solution in the form of a project, and possibly tutorial too, exists.

Regards, Rudy Wieser

Same as on windows, if linux has two or more interfaces it won't route between them unless you tell it you want that.

As Andy says, get a USB ethernet device eg

Put built-in ethernet on one segment and the USB one on the other. Plug adapters into relevant switch/router. Computers on each segment can then "talk" to the pi.

To set up ftp, install vsftpd and see here

The /var/ftp/pub (or /srv/ftp/pub) is then a public directory where any user can upload or download files. If you need more security, come back.

You can use ftp (from the command line) or something like Filezilla from Windows or Linux to up or download files anonymously. /var/log/vsftpd.log will keep a record of who does what and from which IP address.

As I said earlier, this simple install will only be sufficient for an internal ftp server where you can be sure your clients can be trusted.

--

Chris Elvidge, England

Use ftp as the user in vsftpd.conf, make /var/ftp/pub user ftp:ftp

--

Chris Elvidge, England

On Fri, 26 Jun 2020 19:13:04 +0200, "R.Wieser" declaimed the following:

You probably won't achieve that without using very high end serial cables between the two ends, and that cable may need to be a null-modem wiring so that Tx on one end connects to Rx on the other end. Normal serial cables are DTEDCE where the "sense" of the connections is reversed on the DCE side.

(has an error in the dtedce--dcedte diagram -- someone failed to flip the arrows on one side; it should be a mirror image)

Finding any serial cables is getting difficult, much less ones that could take the highest speed (I've got a laptop driving a USBserial DB-9, which then feeds a DB-9DB-25 adapter, onto a DB-25DB-9 cable, all to connect to a Kenwood TS-2000, and I'm having troubles getting reliable signals through that [and the only thing it needs to send is DTR and/or RTS, to toggle the PTT on the radio]).

I need to order a couple of DB-9FDB-9F serial cables, and null-modem cables.

I only suggested using the WiFi during feasibility testing, as the R-Pi

3B+ /has/ two network interfaces... cable and Wifi. After you've worked out what software protocols will provide the desired access, you could consider spending the money for USB dongles.

And on that -- if you're going to spend the money on dongles, might as well go USBEthernet. I suspect you have a lot more CAT-5 (or even CAT-6) jumpers lying around, and many modern Ethernet devices have auto-detect of port polarity (no need to worry if a null-modem or cross-over cable is needed).

{I need the USBserial as I have some old equipment that used serial: the aforesaid TS-2000, old BASIC Stamp boards, I think I have a Propeller board with RS-232, besides having had a previous life where serial was needed. I also have something like three USB2 SIIG USBEthernet dongles -- also from that previous life, and a pair of USB3 SIIG dongles}

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

You're maybe right, I've not had much experience recently, but 10-12 years ago, before I retired, most managed switches I worked with were fine. But then we didn't use el-cheapo switches. But in this case it seems we aren't dealing with vlans - that's a red herring.

Jim

The OP stubbornly refuses to get and set up the hardware which would do what he wants. Both a second USB-Ethernet adapter or a VLAN switch will do the separation.

Using a serial line for tunneling Ethernet fraemes is more challenging, but doable. I have experience, had to do it due to power limitations. An Ethernet interface needs more power than we could feed to a device for exlopsion-proof environment (ExI).

--

-TV

Always. Please killfile.

Well is the Pi already connected to both subnets/LANs? If not then you're going to have to make some new connections aren't you?

--
Chris Green

Might I suggest a google of "data diode", the functionality that you appear to be seeking sounds close to their usage. There are a number of designs in the public domain most of them centered around USB to serial links and optical isolators. If you require two groups of systems to pass data but stay seperate that is probably the sort of solution you are looking for. In the serious security world that type of design is the only authorised way of connecting two systems. Also yes there are Raspberry pi based designs available.

MArt>Guys (Ahem, Jim, Tauno),

sounds like utter, utter overkill for the O/P's requirement.

Maybe, and having looked they can reject the idea as you have, but OP has already stated that he had looked at a serial link and seems concened about system isolation and pro-wired connections. From the thread, they had also apparently been reluctant to adopt the network options, in that context I believe my suggestion is valid albeit at the extreme end of the spectrum. It is possible that they were not aware of the term and so the name as an entry to the literature may be what they are looking for. They don't need to go for full formal design and validation of a certified product to produce a system interconnect that is pretty robust to malicious interference and as originally pointed out there is at least one open source pi based design out there. MArtin

I don't think it's as stupid as you think it is. Nor did clients that have paid me to configure things for them.

Those are perfectly viable options.

But the OP has clearly indicated that he does not want to route TCP/IP (et al.) traffic between the systems. He's going out of his way to NOT do so. His reasons for doing so don't matter. He asked a question, and I provided an answer. I don't want, much less need your validation of it.

--
Grant. . . . 
unix || die

The motivation behind the current state is more important than what the current state is.

I thought such might be the case. Now I know for sure.

ACK

What would you do with the serial connection that you wouldn't / couldn't do with a direct Ethernet connection?

In this context, UUCP is a way to get files between systems A and C, via B, without A and C having the ability to communicate with each other directly.

Push a file:

A$ uucp /path/to/local/file B!C!/path/to/remote/file

Pull a file:

A$ uucp B!C!/path/to/remote/file /path/to/local/file

Both of these commands cause the local system (A) to send a request / file (respectively) to C via B. B receives the request / file and sends it to C. In the pull example, C will send the requested file to A via B. B receives the file from C and sends it to A.

Each of these steps are asynchronous. It's possible to configure UUCP to connect-on-demand. Meaning that as soon as the UUCP system on A has a request / file, it will immediately connect to B. Then once the UUCP system on B has a request / file it will immediately connect to C. ... likewise going back the other way.

A and C do not have any ability to talk directly to each. B must be in the middle of the communications.

Another nice thing is that A and C can communicate via B even if the other end is powered off. A & B talk while C is powered off. Then B & C talk while A is powered off. Then A & B talk (again) while C is powered off.

You can send / pull files, email, news (e.g. Usenet), or even remote commands if you choose to allow them.

All three machines have a modicum of control of what they will allow the other system to request / do.

You can even send files to remote users without specifying where they should go. Conversely, you can collect files that were send to you in the same manner. This is nice for sending a file without worrying where it's supposed to live on the remote end. As if I wanted to send you an mp3 file and have zero knowledge of where you want it saved. Much like an email attachment.

Feel free to follow up with questions, be it here, or email me directly.

I have run versions of UUCP on Windows that exchanged files with my Linux systems without a problem.

Specifically, I had a radio tuner that would record a particular show and save it as a wave file. There was a batch file that was run (after the show) as a Windows Scheduled Task that would convert the wave to an mp3, then use uucp to ""send said mp3 to my server via an intermediate system. (The Windows system could only communicate on the LAN.) The intermediate system would then pass the file on to my web server. My web server would run a nightly script (via cron) that would pick the file up, move it into place, set permissions, and update an RSS feed. Thus I had two systems (A and C) which could not communicate with each other (for security reasons) exchanging files via an intermediary (B) without any problem.

The store and forward nature of UUCP made this extremely resilient. A could go about it's business of recording, converting, and sending files, even if B was inaccessible (b/c A was disconnected from the network). Then once A could communicate with B again, any files that had been queued up would be transferred. Likewise with B and C.

As others have pointed out, this is fairly easy to do. I'll not add to the quagmire that are the responses to that discussion, other than to say that additional USB NICs and / or VLANs can work quite well when configured properly with hardware that properly supports them.

I do not recall transferring files that were bigger than double digit MB through UUCP. But I expect that you could transfer multi-GB files as long as the spool has sufficient room on all systems.

Seeing as how it's UUCP over TCP or SSH, it will move at relatively the same speed as the wire; 10 Mbps, 100 Mbps, etc. So you wouldn't be waiting for serial speeds.

I doubt it. Remember that USB-to-RS232 adapters are meant to be a contemporary UART. That being said, you could probably find USB-to- that will be faster. You might even find that USB-Gadget mode can emulate a serial connection that will run considerably faster than RS-232 and go directly between A & B and B & C.

--
Grant. . . . 
unix || die

The "data diode" is interesting. But the OP has indicated that he wants both systems A and C to be able to both send and receive data, just not without passing through the intermediate B first.

Data Diodes are great for /one/ /way/ communications. Like getting logs out of a secure environment without the ability to send anything into the environment.

--
Grant. . . . 
unix || die

Ahem,

:-) Which is what my initial question started with. Should I just plug a ethernet dongle into an USB port, or are other (and perhaps better) options available ?

Second, how do handle (configure) such an extra interface ? Especially as I do not want either interface to be able to talk to the other without my say-so.

Are there (open source, sourcecode) programs available which will handle such (very restriced) communication ?

As I said, I'm a rather newbie in regard to both Linux as well as the RPi. I could do worse than to work my way thru a tutorial or get my (rather needed) pointers from someone elses project.

:-) Although I know of the latter by way of what Windows offers (SMB), I have no idea what exactly the SAMBA service does or how I should/need to configure it. Let alone which things I all need to disable to be sure no inadverted connections can be made between the interfaces.

Last, but certainly not least, I have no problem with trying to whip up something myself. In fact, that is pretty-much where my hobby lies.

Regards, Rudy Wieser

Martin,

Alas, no. That "data diode" is a one-way communication solution, while I aim at a solution in which /no/ direct communication between the two groups is possible (neither side can poke around the other subnets 'puters and ports thereon).

I already tried a standard DB9 serial connection, but those are, nowerdays, simply too slow to send much of anything over. But yes, I've been taking a peek in that direction too.

The 12 Mbit one looks good. Even its half-speed sibbling would not be too bad. On the other hand, seeing talk about "... have drivers that reliably crash the operating system" doesn't spark much confidence. :-\

I also found some "USB Bridge" references that looked interesting, but there is very little actual info about them (like what kind of USB device do they represent on both sides). And that they seem to be supported by the Windows OS itself could mean they have all the drawbacks of a LAN connection. :-(

Regards, Rudy Wieser

Grant,

Its the other way around: what can't you do with a serial connection that you could do with an ethernet one. You wouldn't be able to portscan just any other 'puter in search of a vunerable service.

Doubt no more. As an example:

Yep. Something called an "USB Bridge". But as I read that it might be supported by the OS as just another network interface it would do exactly what I don't want. :-|

Regards, Rudy Wieser