Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on

Re: 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
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 26.6.20 21:39, Ahem A Rivet's Shot wrote:

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

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

Re: Using an RPi 3B+ as a "post office" between two subnets ?
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

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

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 11:54:16 +0200

The only other real option is VLANs and a smart switch - USB
ethernet is simpler.

That depends - if both networks have DHCP servers then just
configure the new interface to use DHCP (probably default), plug it in and
watch it connect.

You would have to do extra work to get packets passed between them.

Once you have them both connected you can run services listening to
either or both. You could set up samba with a share visible to both
read/write and use it like a drop box, or you could set up an ftp server,

This is pretty much off-the-shelf. In your position I'd probably go
with samba and set up a share or two.

Samba is an open source SMB server, there's a vast amount available
on configuring it.
You don't need to disable anything, you would need to enable
routing for there to be connections between the interfaces.

The only other real option is VLANs and a smart switch - USB
ethernet is simpler.

That depends - if both networks have DHCP servers then just
configure the new interface to use DHCP (probably default), plug it in and
watch it connect.

You would have to do extra work to get packets passed between them.

Once you have them both connected you can run services listening to
either or both. You could set up samba with a share visible to both
read/write and use it like a drop box, or you could set up an ftp server,

This is pretty much off-the-shelf. In your position I'd probably go
with samba and set up a share or two.

Samba is an open source SMB server, there's a vast amount available
on configuring it.
You don't need to disable anything, you would need to enable
routing for there to be connections between the interfaces.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.

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

I was thinking more in the direction of a a "hat" plugged onto the RPi's I/O
connector, but I get the message.

That sounds easy enough.
Part of my problem is that I have no idea what the RPi OS does when it sees
two network interfaces. Under Windows it would blabber all kinds of
(discovery) broadcasts and data over both - which is not what I want to have
happen.

Which would be falling right into the target-zone of my programming hobby.
:-)

Yeah, I know.

That sounds good.
Perhaps even good enough to continue in this direction ...
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 16:51:47 +0200

It *should* be that easy - worst case you have to add a config file
for the USB ethernet.

If DHCP is enabled on the interface (almost certainly) then it will
broadcast a DHCP discover and listen for an offer, once all that has
settled down and it has an IP address it will settle back and listen on it
with any active services (probably only ssh) that haven't been configured
not to (every service I can think of can be configured to listen on a
specific address and/or interface so you can arrange for it to provide
selected services to one network and not the other if you want).

It's not much work - set a flag on the Pi and tell the two subnets
that they can find each other via the Pi. Until you do that the Pi is the
only thing that can see and be seen on both subnets.

I think you'll find it the path of least resistance, and the path
that offers maximum future possibilities.

It *should* be that easy - worst case you have to add a config file
for the USB ethernet.

If DHCP is enabled on the interface (almost certainly) then it will
broadcast a DHCP discover and listen for an offer, once all that has
settled down and it has an IP address it will settle back and listen on it
with any active services (probably only ssh) that haven't been configured
not to (every service I can think of can be configured to listen on a
specific address and/or interface so you can arrange for it to provide
selected services to one network and not the other if you want).

It's not much work - set a flag on the Pi and tell the two subnets
that they can find each other via the Pi. Until you do that the Pi is the
only thing that can see and be seen on both subnets.

I think you'll find it the path of least resistance, and the path
that offers maximum future possibilities.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On June 28, 2020 15:00, R.Wieser wrote:

Effectively, that makes the RPi a router.

I can think of an all-ethernet way of making the RPi a drop-box service
between two unconnected networks, but it might not suit your criteria.
Nevertheless, here it is.
1) the Linux networking stack can support multiple IP addresses on a single
physical ethernet interface. These addresses /do not/ need to belong to
the same subnet, or even the same network.
2) the Linux networking stack can be configured to act as a "host" (rather
than a router), ensuring that the system isolates each network so that
packets are not exchanged between any of the connected networks.
Taken together, this means that you can connect a generic Linux system to
/both/ of your networks, and ensure that the system maintains an isolation
barrier between the networks. So, that one generic Linux system is "visable"
to each network, with it's own unique address /on each network/.
The trick, with the RPi, is to be able to physically connect it to both
networks.
1) On some RPIs, you could hardwire one network to the RPI ethernet port,
and use the built-in wifi to connect to the other network, or
2) hardwire one network to the RPI ethernet port and use a USB-WIFI dongle
to connect to the other network, or
3) hardwire one network to the RPI ethernet port and use a USB-ethernet
dongle to connect to the other network, or
4) hardwire /both/ networks to the RPI ethernet port (this would require
running both networks through a switch, or a router configured as a
"pass-through". (Note that a switch would maintain the independance
and isolation of each network, while allowing both networks to use
a shared cabling infrastructure).
So, my suggestion
a) install a switch and connect it to both networks
b) connect your RPI to the switch
c) configure your RPI as a "host" (no routing between interfaces)
d) configure your RPI ethernet with two "alias" interfaces
a) give one alias interface an address on the /first/ network,
b) give the other alias interface an address on the /second/ network.
e) set up whatever drop-box software you need on the RPI (SAMBA, NFS, ftp,
whatever).
f) there is no "f"
HTH

Effectively, that makes the RPi a router.

I can think of an all-ethernet way of making the RPi a drop-box service
between two unconnected networks, but it might not suit your criteria.
Nevertheless, here it is.
1) the Linux networking stack can support multiple IP addresses on a single
physical ethernet interface. These addresses /do not/ need to belong to
the same subnet, or even the same network.
2) the Linux networking stack can be configured to act as a "host" (rather
than a router), ensuring that the system isolates each network so that
packets are not exchanged between any of the connected networks.
Taken together, this means that you can connect a generic Linux system to
/both/ of your networks, and ensure that the system maintains an isolation
barrier between the networks. So, that one generic Linux system is "visable"
to each network, with it's own unique address /on each network/.
The trick, with the RPi, is to be able to physically connect it to both
networks.
1) On some RPIs, you could hardwire one network to the RPI ethernet port,
and use the built-in wifi to connect to the other network, or
2) hardwire one network to the RPI ethernet port and use a USB-WIFI dongle
to connect to the other network, or
3) hardwire one network to the RPI ethernet port and use a USB-ethernet
dongle to connect to the other network, or
4) hardwire /both/ networks to the RPI ethernet port (this would require
running both networks through a switch, or a router configured as a
"pass-through". (Note that a switch would maintain the independance
and isolation of each network, while allowing both networks to use
a shared cabling infrastructure).
So, my suggestion
a) install a switch and connect it to both networks
b) connect your RPI to the switch
c) configure your RPI as a "host" (no routing between interfaces)
d) configure your RPI ethernet with two "alias" interfaces
a) give one alias interface an address on the /first/ network,
b) give the other alias interface an address on the /second/ network.
e) set up whatever drop-box software you need on the RPI (SAMBA, NFS, ftp,
whatever).
f) there is no "f"
HTH
--
Lew Pitcher
"In Skills, We Trust"
Lew Pitcher
"In Skills, We Trust"

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Lew,

So, all of those 'puters are than electrically connected ? In that case,
how does that stop a 'puter from one "subnet" to try to talk to a 'puter of
another "subnet" ? It just needs to stop or bypass its default gateway,
and away it goes !
Which is pretty-much exactly why I maintain an electrical seperation for my
subnets.
Thanks for the suggestion though.
Regards,
Rudy Wieser

So, all of those 'puters are than electrically connected ? In that case,
how does that stop a 'puter from one "subnet" to try to talk to a 'puter of
another "subnet" ? It just needs to stop or bypass its default gateway,
and away it goes !
Which is pretty-much exactly why I maintain an electrical seperation for my
subnets.
Thanks for the suggestion though.
Regards,
Rudy Wieser

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

Nominally, your (secured) configuration on each system would ensure that
systems neither add themselves to the other subnet nor modify the existing
routing that keeps each subnet logically isolated.

Implying that your system configurations aren't very secure, I guess.

C'est la vie. It was a suggestion, nothing more.
Regards
--
Lew Pitcher
"In Skills, We Trust"
Lew Pitcher
"In Skills, We Trust"

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Lew,

If I would believe each 'puter can be trusted to always behave at its best,
why than should I bother with putting them into different subnet, IP-ranges,
VLANs or whatever ?
No, I've set up my network considering the possibility that one of the
'puters can get the flu. The groupwise isolation makes sure that not all
others get infected too.
Regards,
Rudy Wieser

If I would believe each 'puter can be trusted to always behave at its best,
why than should I bother with putting them into different subnet, IP-ranges,
VLANs or whatever ?
No, I've set up my network considering the possibility that one of the
'puters can get the flu. The groupwise isolation makes sure that not all
others get infected too.
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 21:00:16 +0200

So am I, which is why I was light on detail.

So am I, which is why I was light on detail.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 7:45 AM, Ahem A Rivet's Shot wrote:

It's possible to do this on a single Ethernet connection. It just takes
more knowledge and a little more work.
It's entirely possible to rely on /protocol/ isolation to do what the OP
wants on a /sing.e/ common network.
Hosts A and B can communicate with each other over IPv4 and hosts B and
C can communicate with each other over IPv6. If host A has zero IPv6
support and host C has IPv4 completely disabled, there is no way for
hosts A and C to talk directly to each other.
It's even possible to do this with IPv4. Configure completely different
subnets. Configure firewalling so that hosts A and C block any and all
traffic from each other. Or better, configure hosts A and C so that
they only allow traffic from B.
This filtering could be IP and / or MAC based. I think MAC based would
be simpler and more robust.
There are many ways to do what the OP wants to do on a single Ethernet
interface.
PPPoE, MPLS, etc are options too.

Your suggestions are correct for many environments. However I suspect
that the OP's environment is decidedly different. If the OP has three
devices, hosts A, B, and C cabled together (in a daisy chain), chances
are quite good that there won't be a DHCP server.

Linux (and most other OSs) simply need a setting changed. It's not as
if the OP needs to do something to allow each and every connection.

I sort of suspect that the OP might prefer an (S)FTP(S) server over
Samba. Both Samba and NFS (NAS protocols) can easily have their files
modified (presuming the user has permission) with non-network-aware
scripts / programs. Conversely, (S)FTP(S) is typically not a mounted
file system. As such, there is an access barrier that makes things a
little safer than NAS protocols.
Something a simple as an rm that has gone awry can't effect things on
(S)FTP(S) the same way that it can a mounted NAS file system.

If I were going to do a NAS protocol, I'd use the one that is native to
the platform. Seeing as how the Raspberry Pi is Linux (at least what
we've discussed thus far) I'm going to suggest that NFS be used.
Samba in particular has some down sides compared to NFS related to how
the ""server sees the connections. NFS inherently supports multiple
users over the same connection. Samba does not do so nearly as cleanly.
This may not matter in this situation.

The Linux kernel doesn't forward packets by default. But some Linux
distributions do enable forwarding by default.
He would also need to add routes to A & C so that they would know to get
to each other via B.

It's possible to do this on a single Ethernet connection. It just takes
more knowledge and a little more work.
It's entirely possible to rely on /protocol/ isolation to do what the OP
wants on a /sing.e/ common network.
Hosts A and B can communicate with each other over IPv4 and hosts B and
C can communicate with each other over IPv6. If host A has zero IPv6
support and host C has IPv4 completely disabled, there is no way for
hosts A and C to talk directly to each other.
It's even possible to do this with IPv4. Configure completely different
subnets. Configure firewalling so that hosts A and C block any and all
traffic from each other. Or better, configure hosts A and C so that
they only allow traffic from B.
This filtering could be IP and / or MAC based. I think MAC based would
be simpler and more robust.
There are many ways to do what the OP wants to do on a single Ethernet
interface.
PPPoE, MPLS, etc are options too.

Your suggestions are correct for many environments. However I suspect
that the OP's environment is decidedly different. If the OP has three
devices, hosts A, B, and C cabled together (in a daisy chain), chances
are quite good that there won't be a DHCP server.

Linux (and most other OSs) simply need a setting changed. It's not as
if the OP needs to do something to allow each and every connection.

I sort of suspect that the OP might prefer an (S)FTP(S) server over
Samba. Both Samba and NFS (NAS protocols) can easily have their files
modified (presuming the user has permission) with non-network-aware
scripts / programs. Conversely, (S)FTP(S) is typically not a mounted
file system. As such, there is an access barrier that makes things a
little safer than NAS protocols.
Something a simple as an rm that has gone awry can't effect things on
(S)FTP(S) the same way that it can a mounted NAS file system.

If I were going to do a NAS protocol, I'd use the one that is native to
the platform. Seeing as how the Raspberry Pi is Linux (at least what
we've discussed thus far) I'm going to suggest that NFS be used.
Samba in particular has some down sides compared to NFS related to how
the ""server sees the connections. NFS inherently supports multiple
users over the same connection. Samba does not do so nearly as cleanly.
This may not matter in this situation.

The Linux kernel doesn't forward packets by default. But some Linux
distributions do enable forwarding by default.
He would also need to add routes to A & C so that they would know to get
to each other via B.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 10:45:51 -0600

It also entails more risk.

Yes it is - but it is even more fragile from a security perspective
than VLANs.

Apart from promiscuous mode and/or packet injection.

One glitch in the firewall rules and it all falls open.

The OP explicitly mentions two subnets - so that doesn't fit.

That is indeed the extra work - my point is that it won't just
happen.

That is of course an option and there are many more.

Ouch nasty I've not seen that except on builds meant for routers,
and not on anything common on a Pi.

For everyone but the hackers yes.

It also entails more risk.

Yes it is - but it is even more fragile from a security perspective
than VLANs.

Apart from promiscuous mode and/or packet injection.

One glitch in the firewall rules and it all falls open.

The OP explicitly mentions two subnets - so that doesn't fit.

That is indeed the extra work - my point is that it won't just
happen.

That is of course an option and there are many more.

Ouch nasty I've not seen that except on builds meant for routers,
and not on anything common on a Pi.

For everyone but the hackers yes.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 11:39 AM, Ahem A Rivet's Shot wrote:

Yes, a single Ethernet NIC is more risky than multiple Ethernet NICs.
But there are ways to mitigate it with belt and suspender redundancy.
Depending on the OP's neeed, the simplicity and minimal additional risk
might be acceptable.

I don't completely agree.
It's trivial to have a kernel without IPv6 support. It's slightly more
complicated to have a kernel without IPv4 support. (At least the last I
looked.)
I think that 802.1Q VLAN tagging is great. I've done a LOT with it in
my career. But there are ways around it.

One extremely important thing is do you trust the A & C endpoints? Or
are you considering them to be hostile and defending against them. The
latter requires completely different, and likely more complex, solutions
than the former.

Not necessarily.
You can put the firewall rules on both systems.
You can add static ARP entries.
You can put the systems in separate subnets without a route.
Yes, all of these things can be overcome. But that goes back to the
question of trusting A & C.

The existence of a DHCP server (or not) is independent of subnets.
Besides, what I'm describing would be two different subnets.
|-----| Cable 1 / Subnet A
[A]---[B]---[C] Hosts A / B / C
|-----| Cable 2 / Subnet B

(See comment's below.)

Yep.
It is highly dependent on what the OP is wanting to do.

But it is decidedly a possibility where the OP can end up with the
system routing traffic without doing any additional action. ;-)

Trust of the devices is extremely important.
Even if there is a hacker on A, C will have to have a route to get back
to A. The hacker can't always do it without some support on the other
end for bidirectional communications.
I get the impression that the OP is in control of all three systems, and
as such, probably trusts them about the same.

Yes, a single Ethernet NIC is more risky than multiple Ethernet NICs.
But there are ways to mitigate it with belt and suspender redundancy.
Depending on the OP's neeed, the simplicity and minimal additional risk
might be acceptable.

I don't completely agree.
It's trivial to have a kernel without IPv6 support. It's slightly more
complicated to have a kernel without IPv4 support. (At least the last I
looked.)
I think that 802.1Q VLAN tagging is great. I've done a LOT with it in
my career. But there are ways around it.

One extremely important thing is do you trust the A & C endpoints? Or
are you considering them to be hostile and defending against them. The
latter requires completely different, and likely more complex, solutions
than the former.

Not necessarily.
You can put the firewall rules on both systems.
You can add static ARP entries.
You can put the systems in separate subnets without a route.
Yes, all of these things can be overcome. But that goes back to the
question of trusting A & C.

The existence of a DHCP server (or not) is independent of subnets.
Besides, what I'm describing would be two different subnets.
|-----| Cable 1 / Subnet A
[A]---[B]---[C] Hosts A / B / C
|-----| Cable 2 / Subnet B

(See comment's below.)

Yep.
It is highly dependent on what the OP is wanting to do.

But it is decidedly a possibility where the OP can end up with the
system routing traffic without doing any additional action. ;-)

Trust of the devices is extremely important.
Even if there is a hacker on A, C will have to have a route to get back
to A. The hacker can't always do it without some support on the other
end for bidirectional communications.
I get the impression that the OP is in control of all three systems, and
as such, probably trusts them about the same.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 3:54 AM, R.Wieser wrote:

There are a number of options. Some are more practical than others.

Adding an additional network interface to a Linux machine is fairly
easy. Configuring said Linux machine to not forward traffic between the
two interfaces is also relatively easy. (Linux itself defaults to /not/
forwarding. But some distributions change that.)

That makes me think that you want hosts A and C to communicate with each
other across some routed network. This differs from my previous
understanding of what I thought you wanted. I thought you /explicitly/
wanted hosts A and C to NOT be able to talk to each other at all.
Further, that any ""communications (read: exchange of files / etc.)
would be done but putting files in a common location, B.

Welcome.
If anything, Linux, and the Raspberry Pi suffer from too many options.

Typically, in scenarios like the one you're asking about, it's okay if
the services listen on multiple interfaces on B. The purpose is to
prevent A and C from being able to talk to each other directly. So, A
talking to B on the AB interface is fine, as is C talking to B on the BC
interface. There usually is no harm in something like Samba listening
on multiple interfaces. Presuming you are using the same protocol on A
and C, in some ways having Samba (et al.) on B listen on multiple
interfaces is required.

:-)
Learning opportunities are good. But you may want to avoid painting
yourself into a corner and making things harder on yourself than is
strictly necessary. Why re-create programs if you can use existing
programs. Especially if said existing programs will happily work with
the isolation that you desire.

There are a number of options. Some are more practical than others.

Adding an additional network interface to a Linux machine is fairly
easy. Configuring said Linux machine to not forward traffic between the
two interfaces is also relatively easy. (Linux itself defaults to /not/
forwarding. But some distributions change that.)

That makes me think that you want hosts A and C to communicate with each
other across some routed network. This differs from my previous
understanding of what I thought you wanted. I thought you /explicitly/
wanted hosts A and C to NOT be able to talk to each other at all.
Further, that any ""communications (read: exchange of files / etc.)
would be done but putting files in a common location, B.

Welcome.
If anything, Linux, and the Raspberry Pi suffer from too many options.

Typically, in scenarios like the one you're asking about, it's okay if
the services listen on multiple interfaces on B. The purpose is to
prevent A and C from being able to talk to each other directly. So, A
talking to B on the AB interface is fine, as is C talking to B on the BC
interface. There usually is no harm in something like Samba listening
on multiple interfaces. Presuming you are using the same protocol on A
and C, in some ways having Samba (et al.) on B listen on multiple
interfaces is required.

:-)
Learning opportunities are good. But you may want to avoid painting
yourself into a corner and making things harder on yourself than is
strictly necessary. Why re-create programs if you can use existing
programs. Especially if said existing programs will happily work with
the isolation that you desire.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Grant,

:-) Now I still know nothing.
The thing is I know very few options, and I named both ("hat" and dongle).
However, I do know that using an USB dongle will throttle the speed to that
of the USB port. I have no idea if any of the other possibilities will do
better.

No, no intermediate network. The hosts are always in the same room.

I did, and stil do. But I also said /directly/.
Instead of an UUCP program dropping a file somewhere where the other side
can read it I was thinking of a program which reads a data paccket from one
interface and that writes to the other - in the process dropping all headers
(containing the MAC, IP, port) in either direction (replaced by ones from
the RPi). It would be real-time communication, but definitily not directly.
Hmmmm... Does that UUCP program allow one interface to write a file while
the other interface is reading from it at the same time ? That would be
comparable.

True. As long as that process does not inadvertedly creates some kind of an
U-turn allowing data to pass from one interface to the other (allowing a
direct A-to-C communication). Yeah I know, that sounds a bit paranoid,
but its better to make sure that that can't happen than (much) later pay the
price for it.

Agreed. But I would not have any qualms to install SAMBA twice, once for
each interface, only coming together on the file-storage level.

The former doesn't automatically follow from the latter.

Why else ? Because I want to see if I can do it myself. :-) Its also a
good(?) way to get to know the OS a bit under its surface. Besides, if that
fails I can always fall back on stuff that others wrote.

They won't. But as I have quite a bit of experience with programming and
TCP/IP on a Windows machine I don't think that writing a program for it*
will give me much trouble.
*simple file-transfer first, maybe automatic clipboard exchange later.
Regards,
Rudy Wieser

:-) Now I still know nothing.
The thing is I know very few options, and I named both ("hat" and dongle).
However, I do know that using an USB dongle will throttle the speed to that
of the USB port. I have no idea if any of the other possibilities will do
better.

No, no intermediate network. The hosts are always in the same room.

I did, and stil do. But I also said /directly/.
Instead of an UUCP program dropping a file somewhere where the other side
can read it I was thinking of a program which reads a data paccket from one
interface and that writes to the other - in the process dropping all headers
(containing the MAC, IP, port) in either direction (replaced by ones from
the RPi). It would be real-time communication, but definitily not directly.
Hmmmm... Does that UUCP program allow one interface to write a file while
the other interface is reading from it at the same time ? That would be
comparable.

True. As long as that process does not inadvertedly creates some kind of an
U-turn allowing data to pass from one interface to the other (allowing a
direct A-to-C communication). Yeah I know, that sounds a bit paranoid,
but its better to make sure that that can't happen than (much) later pay the
price for it.

Agreed. But I would not have any qualms to install SAMBA twice, once for
each interface, only coming together on the file-storage level.

The former doesn't automatically follow from the latter.

Why else ? Because I want to see if I can do it myself. :-) Its also a
good(?) way to get to know the OS a bit under its surface. Besides, if that
fails I can always fall back on stuff that others wrote.

They won't. But as I have quite a bit of experience with programming and
TCP/IP on a Windows machine I don't think that writing a program for it*
will give me much trouble.
*simple file-transfer first, maybe automatic clipboard exchange later.
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 11:48 AM, R.Wieser wrote:

Seeing as how you are wanting to do something akin to a proxy for TCP
traffic, I would suggest that you use a USB-to-Ethernet dongle for a 2nd
Ethernet interface.
As others have stated, a Layer 2 managed switch using 802.1Q VLAN tags
is a perfectly viable option too.
Which you use will probably depend on what you have available and / or
want to purchase.

I suspect that USB will actually be faster than any hat that uses GPIO
pins. I could be wrong about this. But I would bet a cup of coffee.

A routed network doesn't necessarily mean that there is something in
between the networks.
|-----| Cable 1 / Subnet A
[A]---[B]---[C] Hosts A / B / C
|-----| Cable 2 / Subnet B
A would have a route to the BC network via B (AB interface)
C would have a route to the AB network via B (BC interface)
You can also use a default gateway instead of more specific routes. But
that's more minutia of what the route is. What it does is still
functionally the same thing.
That assumes that A and C are addressing packets to each other.
There is another possibility, which I call a "Customer Interface
Router". Typically seen where a non-small business (think national
paint brand) interfaces with a bunch of small outlets that they
interface with in such a way as to not have to complicate the big
network with routes to all the smaller networks. Or conflicts between
the smaller networks.
The C.I.R. NATs both the source and destination addresses of traffic
flowing both ways through the C.I.R. The parent company can send
printer traffic to the C.I.R. and C.I.R. will then alter the traffic so
that it is now to the printer and from the C.I.R. Similarly, someone in
the small office can open a terminal connection to the C.I.R. and the
C.I.R. will alter the traffic so that it is now to the corporate server
and from the C.I.R. Neither the parent company nor the small subsidiary
need to know anything about the others network (beyond what's needed to
configure the C.I.R.). They both simply talk to the C.I.R. This type
of setup is typically done with NAT.
But another option is an application layer gateway / proxy. Host an LPR
server (daemon) on B / the C.I.R. and have it actively be part of the
printer path. Likewise with the terminal server.
So, which is better. It depends. NAT can usually be done with
relatively simple devices (comparatively) than a full Application Layer
Gateway / Proxy. But, the ALG / Proxy usually gives more (filtering)
capability.

Geography and physical locality actually have very little to do with it.
Intermediate networks are /easier/ but are not /required/. It's
possible to have the /same/ network spread around the globe.

Okay. - I think we need to zoom in a level.
Do you want A and C to be able to establish TCP connections with each
other? E.g. through a router of some sort?
Or do you want A to *ONLY* be able to establish a TCP connection with B,
and likewise with B & C? - Note: This is independent of what B does
with the traffic from the established TCP connection.
Aside: The same can be said about UDP and other protocols on top of IP.
But I'm focusing on TCP for this discussion.
This may seem like a minutia difference. But it is a very important
difference. If you're okay with A and C establishing a TCP connection
with each other through an intermediate router (B), then much of this
conversation is moot. Like a mic drop.
If you want A and C to not be able to establish a TCP connection with
each other in any way shape or form, then we do need to continue talking
about other options.

Now you're talking more about something between NAT and an ALG / Proxy.
You don't even need Samba / NFS / etc. on the intermediate host B.
A will /think/ that it's talking to B when in fact it's /really/ talking
to C. Likewise, C will /think/ that it's talking to B when in fact it's
/really/ talking to A. It's just that A and C will have a different
idea of what each other's address is.
It's important to note that A can still send traffic to C, via B, that
is malformed and potentially attack C. And vice versa.
This is one of the things that the intermediate file drop helps avoid.
Network level attacks are effectively moot. There is no network
communications between A and C when using a file drop.

No. Not as such. UUCP works by running a command on A that tells UUCP
on A, B, and C, to transfer the file to C.
A$ uucp /local/file/path B!C!/remote/file/path
Much like you could use the cp or scp command.
UUCP on A, B, and C, then do their thing to transfer the file between A
and C via B on your behalf.

I have some concerns about Samba, particularly the NetBIOS Session
Service (NBSS) which ? as I understand it ? is intended to do exactly
that. But that doesn't mean that you actually have to use the NBSS
functionality.
Network Attached Storage (NAS) file drops ? or "post office" ? generally
only provide a place that A or C can put files for the other to pick up.

Remember, even a file drop, can enable programs on A and C to
communicate with each other. Much like we are ""interactively
communicating with each other through Usenet. It's just highly latent
compared to a more typical TCP connection.
A true file drop / post office has the advantage that the file is
written (by A), something (on B) can check it and only move it to where
the other (C) can get it /if/ it passes muster. This typically means
that only specific /known/ to be good types of communications are
allowed. Such a filtering file drop will detect and block abnormal
communications.
NAT quite likely can't do this type of filtering.
An ALG / Proxy might be able to do this type of filtering.

You only install Samba once. You only need to run one instance of it.
(In fact, running multiple instances of Samba used to be quite
difficult.) The same single instance would listen on multiple interfaces.

Agreed.
Because you have a couple of systems from different 3rd party vendors
that you want to exchange files but the current configuration doesn't
allow it and the vendor(s) won't reconfigure things without paying (a
lot of) money.
Because you want to go between systems that don't speak a common
protocol. Say NCP on one side and IPv4 on the other. Or IPX and
AppleTalk. Or DECnet and NetBIOS. ;-)

I honestly don't need anything stronger than that.

True.
Fair enough.
I was thinking industry standard news and email servers & clients on
each end exchanging files through the intermediary.

There are a lot of ways to solve this problem.

Now you're talking about something a LOT more involved. Many
traditional remote control applications support this. But I'm not aware
of any that will work without an established network connection of some
sort. I'm betting virtually none of them will work through a pure file
drop / post office communications mechanism. Save for writing the
clipboard contents to a file, transferring it, and loading it on the
other end.

Seeing as how you are wanting to do something akin to a proxy for TCP
traffic, I would suggest that you use a USB-to-Ethernet dongle for a 2nd
Ethernet interface.
As others have stated, a Layer 2 managed switch using 802.1Q VLAN tags
is a perfectly viable option too.
Which you use will probably depend on what you have available and / or
want to purchase.

I suspect that USB will actually be faster than any hat that uses GPIO
pins. I could be wrong about this. But I would bet a cup of coffee.

A routed network doesn't necessarily mean that there is something in
between the networks.
|-----| Cable 1 / Subnet A
[A]---[B]---[C] Hosts A / B / C
|-----| Cable 2 / Subnet B
A would have a route to the BC network via B (AB interface)
C would have a route to the AB network via B (BC interface)
You can also use a default gateway instead of more specific routes. But
that's more minutia of what the route is. What it does is still
functionally the same thing.
That assumes that A and C are addressing packets to each other.
There is another possibility, which I call a "Customer Interface
Router". Typically seen where a non-small business (think national
paint brand) interfaces with a bunch of small outlets that they
interface with in such a way as to not have to complicate the big
network with routes to all the smaller networks. Or conflicts between
the smaller networks.
The C.I.R. NATs both the source and destination addresses of traffic
flowing both ways through the C.I.R. The parent company can send
printer traffic to the C.I.R. and C.I.R. will then alter the traffic so
that it is now to the printer and from the C.I.R. Similarly, someone in
the small office can open a terminal connection to the C.I.R. and the
C.I.R. will alter the traffic so that it is now to the corporate server
and from the C.I.R. Neither the parent company nor the small subsidiary
need to know anything about the others network (beyond what's needed to
configure the C.I.R.). They both simply talk to the C.I.R. This type
of setup is typically done with NAT.
But another option is an application layer gateway / proxy. Host an LPR
server (daemon) on B / the C.I.R. and have it actively be part of the
printer path. Likewise with the terminal server.
So, which is better. It depends. NAT can usually be done with
relatively simple devices (comparatively) than a full Application Layer
Gateway / Proxy. But, the ALG / Proxy usually gives more (filtering)
capability.

Geography and physical locality actually have very little to do with it.
Intermediate networks are /easier/ but are not /required/. It's
possible to have the /same/ network spread around the globe.

Okay. - I think we need to zoom in a level.
Do you want A and C to be able to establish TCP connections with each
other? E.g. through a router of some sort?
Or do you want A to *ONLY* be able to establish a TCP connection with B,
and likewise with B & C? - Note: This is independent of what B does
with the traffic from the established TCP connection.
Aside: The same can be said about UDP and other protocols on top of IP.
But I'm focusing on TCP for this discussion.
This may seem like a minutia difference. But it is a very important
difference. If you're okay with A and C establishing a TCP connection
with each other through an intermediate router (B), then much of this
conversation is moot. Like a mic drop.
If you want A and C to not be able to establish a TCP connection with
each other in any way shape or form, then we do need to continue talking
about other options.

Now you're talking more about something between NAT and an ALG / Proxy.
You don't even need Samba / NFS / etc. on the intermediate host B.
A will /think/ that it's talking to B when in fact it's /really/ talking
to C. Likewise, C will /think/ that it's talking to B when in fact it's
/really/ talking to A. It's just that A and C will have a different
idea of what each other's address is.
It's important to note that A can still send traffic to C, via B, that
is malformed and potentially attack C. And vice versa.
This is one of the things that the intermediate file drop helps avoid.
Network level attacks are effectively moot. There is no network
communications between A and C when using a file drop.

No. Not as such. UUCP works by running a command on A that tells UUCP
on A, B, and C, to transfer the file to C.
A$ uucp /local/file/path B!C!/remote/file/path
Much like you could use the cp or scp command.
UUCP on A, B, and C, then do their thing to transfer the file between A
and C via B on your behalf.

I have some concerns about Samba, particularly the NetBIOS Session
Service (NBSS) which ? as I understand it ? is intended to do exactly
that. But that doesn't mean that you actually have to use the NBSS
functionality.
Network Attached Storage (NAS) file drops ? or "post office" ? generally
only provide a place that A or C can put files for the other to pick up.

Remember, even a file drop, can enable programs on A and C to
communicate with each other. Much like we are ""interactively
communicating with each other through Usenet. It's just highly latent
compared to a more typical TCP connection.
A true file drop / post office has the advantage that the file is
written (by A), something (on B) can check it and only move it to where
the other (C) can get it /if/ it passes muster. This typically means
that only specific /known/ to be good types of communications are
allowed. Such a filtering file drop will detect and block abnormal
communications.
NAT quite likely can't do this type of filtering.
An ALG / Proxy might be able to do this type of filtering.

You only install Samba once. You only need to run one instance of it.
(In fact, running multiple instances of Samba used to be quite
difficult.) The same single instance would listen on multiple interfaces.

Agreed.
Because you have a couple of systems from different 3rd party vendors
that you want to exchange files but the current configuration doesn't
allow it and the vendor(s) won't reconfigure things without paying (a
lot of) money.
Because you want to go between systems that don't speak a common
protocol. Say NCP on one side and IPv4 on the other. Or IPX and
AppleTalk. Or DECnet and NetBIOS. ;-)

I honestly don't need anything stronger than that.

True.
Fair enough.
I was thinking industry standard news and email servers & clients on
each end exchanging files through the intermediary.

There are a lot of ways to solve this problem.

Now you're talking about something a LOT more involved. Many
traditional remote control applications support this. But I'm not aware
of any that will work without an established network connection of some
sort. I'm betting virtually none of them will work through a pure file
drop / post office communications mechanism. Save for writing the
clipboard contents to a file, transferring it, and loading it on the
other end.
--
Grant. . . .
unix || die
Grant. . . .
unix || die
Site Timeline
- » BMP180 Barometric pressure sensor - deviates about 8 full points from expected
- — Next thread in » Raspberry Pi Group
-
- » BMP180 barometric sensor (I2C) not detected.
- — Previous thread in » Raspberry Pi Group
-
- » My darn NAS UPDATE...
- — Newest thread in » Raspberry Pi Group
-
- » Battery Powered Project
- — Last Updated thread in » Raspberry Pi Group
-
- » continuo comparatore a finestra OK
- — The site's Newest Thread. Posted in » Electronics Hobby (Italian)
-
- » Basette millefori 230 x 160 dove trovarle ?
- — The site's Last Updated Thread. Posted in » Electronics Hobby (Italian)
-