On 6/28/20 7:45 AM, Ahem A Rivet's Shot wrote:
> The only other real option is VLANs and a smart switch - USB ethernet
> is simpler.

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.

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

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.

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

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.

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

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.

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

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.

> You don't need to disable anything, you would need to enable routing
> for there to be connections between the interfaces.

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

--- SoupGate-Win32 v1.05