[HECnet] Connections?

[Mark Pizzolato]

Dave,

What you’ve described is how I’ve understood networking to work all along.

Mark Abene’s comments suggested otherwise especially since he described that something used to be a restriction which no longer is.

The earliest efforts to get simh networking to talk to host systems, we described the easy way, and a more complicated way.  The easy way was to have a dedicated host LAN interface for the simh instance have that interface connected to the same LAN as the host system’s primary interface.  This was a platform independent solution which was relatively easy to setup.  The more complicated way was the approach you’ve described using a bridge interface within the host system that bridges the LAN to the bridge ‘pseudo’ interface and the HOST and GUEST(s) connect to the bridge via tap or some other host unique way.  This worked for essentially any *nix platform which had some bridge implementation as well as Windows, but it required manual reconfiguration of the host system’s network setup.

The only ‘change’ to known restrictions has been a third ‘ridiculously easy’ way which is available on Windows.  On Windows the host and any number of guest systems can share the same physical interface (as long as each guest uses unique MAC and IP addresses).  No change to network setup is required.  Windows has this ‘ridiculously’ easy option since raw packet transmission on Windows (via pcap_send_packet) injects the outgoing packet at a point in the Windows network stack where it is also seen by the incoming network stack.  This then allows host<->guest traffic with no other messing around.  On other platforms, pcap_send_packet presents the outgoing packet directly to the LAN without touching the incoming side of the host system’s network stack, thus the use of a bridge is required to get the host to see the guest transmitted traffic.


-          Mark

From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of dwe-6006 at philtest.org
Sent: Saturday, May 5, 2018 11:51 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Connections?

The case of multiple simulated systems talking to each other as well as talking to the host is pretty simple but it does require that the guests and the host all have unique IP addresses. In this case just set up software bridge that connects tap devices for each guest to the physical Ethernet adapter for the host. The guests can have unroutable addresses as long as the host understands that they exist on the bridge. It’s less ugly if the host has a secondary address in the unroutable subnet but brute force will work nicely if necessary.

Where the multiple simulated systems need to speak to each other and the host and the Internet, the easy way is the tap and bridge solution  but all the devices require unique and routable IP addresses.  Where routable IP addresses are at a premium then the tap and bridge alone will not work and the options range from NAT (which can be painful) to  using one of the software virtual routers like dynamips running a suitable version of Cisco IOS or the DD-WRT appliance (which can also be painful)

Dave



From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Pizzolato
Sent: Saturday, May 5, 2018 1:56 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Connections?

Hi Mark,

I’m not understanding what you saying here.

Are you suggesting that on a single host system, you’ve got multiple independent simulators running which all are using the same IP address as the host system? And, if true these devices can then, not only uniquely communicate with remote systems (on the Internet say), and also to each other AND the host system?


-          Mark

From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Abene
Sent: Saturday, May 5, 2018 10:45 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] Connections?

This is an often misunderstood generalization, with some people able and others not. I remember this being true on *BSD. You could not connect to a simulated IP on the same host. It *used* to also be true on Linux, but is no longer the case for some time. On my ubuntu server where I run dynamips, simh, and klh10, all on bridged taps, I can telnet to all instances, even locally.

-Mark



On Sat, May 5, 2018, 12:27 AM Johnny Billquist <bqt at softjar.se<mailto:bqt at softjar.se>> wrote:
On 2018-05-05 03:39, Robert Armstrong wrote:
>>since once Multinet grabs the interface, I can’t get to the underlying
> host.
>
>    Actually I think it’s a limitation in simh and the pcap library – the
> simh guest OS can’t talk to the host OS on the same interface.  You can
> work around the problem with a TAP device.  Check the archives for the
> simh mailing list – it’s been discussed many times before.

No. That is not correct. I run simh myself on a machine where I have
both the native host and simh talking on the same ethernet. And they are
both reachable by other hosts.
The OP must be doing something else funny.

   Johnny

--
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se<mailto:bqt at softjar.se>             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20180505/f5bb57d9/attachment-0001.html>