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

Dennis,



I know.   But you are going fully outof scope I'm afraid.

Also, I think you missed the part where I describe that both 'puters connect  
to the Pi - The Pi does *not* connect to the 'puters - and *especially not*  
to random ports.



:-) That single port access is not intended for random programs to connect  
to.  Just /my/ program, which transfers whatever I like to another of /my/  
programs receiving it on the other side.

But, if I ever want to have random programs on one side to connect to random  
programs on the other side (which is exactly what I *don't* want !)  than I  
could imagine starting a "connection" with a single block of data indicating  
the intended target - perhaps implementing something like the "ports" scheme  
TCP/IP already has .... :-)

Regards,
Rudy Wieser

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.

MArtin

wrote:

snipped-for-privacy@notvalid.pig wrote:



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

wrote:



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  

On 6/27/20 2:57 AM, snipped-for-privacy@notvalid.pig wrote:


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.

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.

https://www.sjoerdlangkemper.nl/2019/03/20/usb-to-serial-uart/

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  

declaimed the following:



    Not really...

    The key is that the A is for "asynchronous"... Each byte is sent as a
discrete entity -- in 8n1 configuration, each 8 bit byte is sent as a 10
bit entity (start bit, 8 data bits, stop bit) [If you use parity with 8
data bits, you'll end up sending 11 bits total].

    Ethernet is a synchronous system... there are a few bytes for
synchronizing, but then the entire information packet gets sent without the
start/stop bits between bytes. True, there is some overhead for IP/port
information, and over that for the MAC address information. Also, the
packets have a checksum for error detection.

    At one time, one could find USART chips, which could handle
asynchronous or synchronous transmissions (but in those days, a high-speed
USART was around 38400 bps <G> ).


    If you have an R-Pi 3B+ and a WiFi router you may already have a test
case you can perform... Use a CAT-5/CAT-6 cable from the R-Pi to one of
your separated networks, and configure the R-Pi WiFi to connect to the
other network with the WiFi router. Then try SSH connections from each
network to the R-Pi.

Dennis,


....

I'm aware of that  But as USB speeds are much higher I could imagine that  
some of that translates to higher serial speeds too.  Like the below link  
already shows a 3.5 times higher speed than a regular UART.

http://www.a2s.pl/en/atc-810-p-3703.html



:-)  Nope.  Both will be wired (like all my connections), or nothing goes.

Regards,
Rudy 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 DTE<>DCE where the "sense" of the connections is reversed on the
DCE side.

https://zone.ni.com/reference/en-XX/help/370984T-01/lvaddon11/987x_rs232dtevsdce/
(has an error in the dte<>dce--dce<>dte 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 USB<>serial DB-9,
which then feeds a DB-9<>DB-25 adapter, onto a DB-25<>DB-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-9F<>DB-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 USB<>Ethernet. 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 USB<>serial 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 USB<>Ethernet dongles -- also from
that previous life, and a pair of USB3 SIIG dongles}

On 6/26/20 3:15 AM, R.Wieser wrote:


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-<something other than RS-232> 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,



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:
https://www.sjoerdlangkemper.nl/2019/03/20/usb-to-serial-uart/#chip-differences



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

R.Wieser wrote:



There's *nothing* you can't do if you run PPP over your serial  
connections, they'd have a full TCP/IP stack and you could ping,  
portscsan, ftp, ssh to your hearts content ... not that I suspect you'd  
want to.

However I guess must people here are left wondering why you think you  
need absolute network isolation for a handful of rPis that, let's face  
it,  are unlikely to be running fort knox, or a nuclear power plant, and  
that you could likely get a suitable level of isolation for your  
purposes over a single ethernet port using VLANs ...

On Sun, 28 Jun 2020 13:15:05 +0100, Andy Burns



I agree.


And/or iptables to drop any traffic that is not allowed by
network interface, source and destination IP-address, and port.

On 6/28/20 5:00 AM, R.Wieser wrote:


The biggest one is speed.

There are some other more esoteric things that can be done (much much  
much easier) on Ethernet.

Ethernet can easily be point-to-multipoint supporting more than two  
computers.  RS-232 can't do that.  (Yes, other serial specifications  
can, but they aren't on the Pi.)



Depending on how you use the serial interface, yes, you can port scan  
other computers across the serial connection.  SLIP and PPP come to  
mind.  Have you ever used the Internet over a dial-up-modem?  ;-)



I still doubt it.  I remember seeing high single / low double digit Mbps  
on UARTs in the past.

The fact that the UARTs are hanging off of a USB interface doesn't  
change the fact that they are still a UART.



It will depend on the type / mode of USB communications that is used.

Yes, USB Gadget /can/ appear as a network interface.  USB Gadget can  
appear as a /serial/ interface.  (This underlying serial / USB  
functionality is how USB-to-RS-232 adapters work.)  Linux has the  
ability to pick /which/ gadget mode(s) are used.  As such, you can make  
a USB connection look like a serial connection and not a network connection.

On Sun, 28 Jun 2020 10:56:25 -0600



    Of course it can, each link is point to point but nothing restricts
a computer to a single serial port. Way back we used to use Altos Micnet to
create a LAN based on UUCP over whatever topology of serial connections you
cared to make. These days PPP would be a much better option.

On 6/28/20 1:10 PM, Ahem A Rivet's Shot wrote:


You just said what I said.  "Each (RS-232) link is point to point".  End  
of story.



I completely agree.

But now you are talking about something decidedly outside of the scope  
of "each link".  ;-)



Sure.  That's the software that interconnects multiple machines on top  
of many point-to-point links.

RS-485 supports physically connecting more than two machines to the same  
physical link.  No additional software needed to copy things from link  
to link.  ;-)

On Sun, 28 Jun 2020 13:37:16 -0600



    Ethernet is the same ever since co-ax died, it's all point-to-point
we just call the (rather specialised) computer with a lot of ports a switch.



    It runs in the switches these days but it is still there.



    Indeed it does - but multi-drop interfaces are mostly out of fashion
these days (apart from open air ones of course).

On 6/28/20 3:00 PM, Ahem A Rivet's Shot wrote:


There is room for debate.  Especially with how switches deal with  
Broadcast / Unknown / Multicast frames.  ;-)

I used to say at an old job, when a computer farts at the waste water  
treatment plant on the south west side of town, computers at the dump on  
the north east side smelled it.  It was a giant L2 network.



No, switches do something decidedly different than what UUCP / SLIP /  
PPP / routing stacks do.

Switches effectively block or forward traffic based on a condition.  
Where as UUCP / SLIP / PPP / routing stacks / et al. actually modify the  
packets that flow through them.  Also, switches are non-terminal.  The  
others are decidedly terminal from an L2 perspective.



"Mostly" being the operative word.  There are still some multi-drop  
installations used for special things.  I've also seen traditional point  
to point circuits (fiber optic connections) tapped in a way that two  
devices can actually be connected to the circuit as a form of active /  
backup redundancy.

On 23/06/2020 06:34 pm, R.Wieser wrote:


Assuming that everything is internal, and you don't have massive  
security issues, why not try ftp (vsftpd is good). Set up 2 network  
ports, one for each network - one internal, one wifi (or, better, usb).
Make sure you have forwarding off. You could put some iptables rules to  
limit filter inputs.

Set up /var/ftp/pub where anyone can drop the file(s) of interest - from  
either network and run a cron job to check for differences in the file  
list of /var/ftp/pub. Use a nullmailer then to send an email message to  
all the possible recipients saying something like fileXYZ is available  
for pickup. Note: you need an mua and mta or the receiving machines.

You could have several directories, each associated with either a  
sending computer or a sending user and/or a receiving computer/user.

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