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