On 6/28/20 3:23 PM, R.Wieser wrote:
> Thanks.  I already got that idea too, but as I know almost nothing
> about the possibilities ...

Fair enough.

Forums like these are good for casting a wide net and filtering through
the catch to learn about new things that might be of value.

> Well, I'm most always going for a solution that is easiest to manage
> and has the largest usage area - even when I almost certainly will
> never move the thing.

ACK

I'm known among my friends as someone who frequently doesn't go for the
easiest / simplest / fastest / cheapest solution.

> IOW, when executed my choice will be the dongle.

Whatever works for you.

> As far as I can see B is in between the AB and BC networks ...

Yes.

I've been assuming a configuration like this.

[A]---[B]---[C]

Where hosts A and C are your two systems and B is the Raspberry Pi.

I've simply combined the letters of the systems that are connected as a
simple identifier for the network.

  |-----|          AB network connects to systems A and B.
[A]---[B]---[C]
        |-----|    BC network connects to systems B and C.

B has an interface in the AB network and another interface in the BC
network.

> But yes, I was imagining a routing over yet another LAN segment.

In my diagram above:

A is connected to the AB network
C is connected to the BC network

Here's another view that might be less confusing about links.

  |-----|          AB network connects to systems A and B.
[A]   [B]   [C]
        |-----|    BC network connects to systems B and C.

> Nope, never.

Does that mean that you will terminate the TCP connections from A /on/ B
and initiate a /new/ connection from B to C?  (And vice versa.)

> Yep, that.    And to be honest, I could not care less how it happens,
> as long as they can exchange data without actually being able to
> connect set up random connections to each other.

Well, you do care.  You can use traditional routing through B combined
with firewalling to prevent them from being able to set up random
connections to each other.  You might not realize that you care.  But
your statements demonstrate that you do care.

> Hence my side-step in the direction of a serial connection.   Data can
> flow, but without specially written software that data comes from
> nowhere and goes to nowhere else than from/into my program.

You say that.  But said specially written software has existed in the
Linux kernel for 20+ years.

> Not quite.  As I said, the port information is dropped too.  Always.

The /old/ port information (A to B) may be dropped.  But there is /new/
port information (B to C) created.  You will also care very much about
ports if you are using typical sockets and the Linux TCP/IP stack.

You may not care about ports as far as the data making it from A to C is
concerned.  But you will care about ports in the programs that you use /
write.

> Yep.  But with a small twist: In my initial idea B was truly passive.
> Receiving a connection from A would not provoke it to try to make a
> connection to C.  It would do nothing until C also connected to it.
> Only than it would exchange datapackets.

So B is definitely going to be active in that it will be a TCP endpoint
for A, also independently be a TCP endpoint for C, as well as actively
copy data between the two endpoints when the time is correct.

B may not /initiate/ the connections.  But it will very much be an
active participant in each of the connections.

> Currently I'm cautiously sporting the idea that /maybe/ B could,
> when receiving a connection from either side, open a connection to
> the other side itself - on a fixed port ofcourse.

 From a networking perspective, this is somewhat simpler than the
scenario above.  In this case, B doesn't need to participate in the TCP
connection (windows, sequence numbers, etc.).  Instead, it can (almost)
transparently pass the information between A and C while allowing A and
C to deal with the minutia of TCP/IP.

> Ah, I misunderstood what it might do.

;-)

> Yes, I'm aware of that.    The whole idea is that I /want/ them to
> communicate - but only on my conditions.

"on my conditions" implies some sort of /active/ decision making.  ;-)

> I understood that.   It was just to make a point as to how far I
> would go to keep everything apart.

Fair enough.

If you want to be crazy about it, you could have two pies each connected
to their respective system, Samba, and DRBD between the Pis.  }:-)

> Not really.   I wrote something like that a number of years ago. Text
> only though.  That was all I needed it for.  And I never actually
> finished the "automatic" part though. I would have needed a data-hash
> check to stop data storms, but eventually dropped that idea.   Instead
> I simply used a "send" button.  Served two purposes: No data storms,
> and being able to copy-paste private data without automatically having
> it land on other 'puters.

I still maintain that interfacing with the system clipboard on multiple
systems is more complicated than a simple file drop.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05