[Simh] Using TAP/TUN

[Mark Pizzolato - Info Comm]

On Monday, March 05, 2012 at 11:31 PM, Michael Bloom wrote:
> The case you mention in your last paragraph is indeed one of my
> concerns.  I have been picturing eventually putting several simulators
> (ITS, TOPS-20, VMS, 2.11BSD,   RSX-11M, and maybe someday an OS for a
> newer architecture) on a single lightweight machine (perhaps a higher-
> powered carry-anywhere tablet) all networked together within the tablet
> which itself connects to a wireless router. **(elaboration below)
> 
> So your points, particularly about transparent compatibility, are well
> taken.
> 
> For the time being, however,  I'm using a linux laptop to experiment
> with.
> 
> After reading your message, I decided to try bringing up a couple of
> SIMH's at the same time, first using two tunnels.  As expected, the
> tunnels could each communicate with the host and outside world, but not
> with each other.
> 
> So I decided to then use a full tunnel and bridge combination, as
> described in 0readme_ethernet.txt
> 
> And that's where I ran into trouble.  The laptop only connects to the
> router via a wireless interface.
> 
> The bridge-utils-interfaces(5) man page does not recommend using a
> bridge with such an interface. But more than that, when I tried to add
> the wireless interface to a bridge,  I got an "Operation not supported"
> message".  I haven't determined yet whether it is that the wireless
> card driver does not want the IF to be part of a bridge at all, or
> whether it does not want to be part of a bridge when it's using an
> access point, or ???
> 
> So for the moment, I'm stuck with a single SIMH instance until I can
> set up a wired connection to the router so I don't need to use the
> wireless
> lan.   But that's not realistic for the long term.
> 
> I'm going to try to investigate whether anyone has  come up with
> something new that might be more portable and general than existing
> approaches, and was intended to resolve similar types of issues (when
> encountered by VM's such as VMware or virtualbox, for example).  A pre-
> assembled virtual router that could be used with tunnels, wireless
> interfaces, ethernet interfaces, etc., (but operated independently from
> the host's routing facilities) might be an interesting find, for
> example.

Since you're exploring this subject somewhat deeply, first, I hope you're working from the current codebase at https://github.com/markpizz/simh 

Once there, you may want to look into the potential of advanced configurations of the existing VDE networking support built into simh already.  It doesn't change the issues you're looking at, but all of the issues you're trying to address are likely solvable on the VDE side.  I added the VDE support and only tested it minimally since I found that someone had thought it useful to add VDE and left a public repository with the code on github (https://github.com/promovicz/simh).  This author never mentioned this work to the community at large (or I never saw it), so VAST changes had already taken place to the current versions of sim_ether before I saw this.  The changes I'd already done to what he'd started from were so significant that I didn't try to merge but merely took the idea and some details from his work and did it myself.  Since my primary system is not Linux I didn't explore (or write up) all of the potential ways that VDE could be used.  I believe that VDE provides the physical network layer for at least one other simulator type environment.

You are on the right track looking at other full featured products.  The source for VirtualBox is publicly available.

If you're host box is using a wireless network interface, the limits of the WiFi layer and the restrictions of the WiFi Router and/or Access Point will generally not let more than one physical address pass in and/out of the WiFi interface.  Hence, bridging in this scenario is not a choice.

One issue with the 'full featured (packaged) products' is that they may solve these problems with a set of programs which may need to be run together depending on the network goals.  Some of these 'programs' may actually be kernel drivers (certainly the case for VirtualBox's network layer on Windows).  If we looked closely enough at VirtualBox's implementation, we might be able to leverage these additional VirtualBox provided components (if VirtualBox is installed) and act (to the networking components layer) like a VirtualBox simulator.

VirtualBox has several choices for how their networking layer behaves for a given simulator (VM)'s network interface:  0. not Attached, 1. NAT, 2. Bridged Adapter, 3. Internal Network, 4. Host Only Adapter, 6. Generic Network.  The setting defaults to NAT, which allows the VM to talk to the outside world via IP (it may also provide a DHCP server to assign an IP address to the simulator).  The setting should be Bridged Adapter (AND the advanced setting of "Promiscuous Mode: Allow All") if you want to run a simh simulator inside an OS running in the VM.

Please let us know what you learn.

- Mark

> - Michael
> 
> **note : The (possibly manic) idea was  to have, essentially, a single
> physically portable appliance capable of running nearly any serious
> educational software ever written for a variety of machines; whether
> the student needs Macsyma for her engineering classes, or RSTS/E BASIC
> and SPSS for retro business classes (this is after all, just an
> example), it can run on her universal computing tablet, and by
> retaining physical possession of the machine and it's contents, she can
> feel comfortable knowing she has control over whether anybody can
> plagiarize her work, a feeling more difficult for her to attain with
> "cloud computing".
> 
> 
> On 03/05/2012 05:55 AM, Mark Pizzolato - Info Comm wrote:
> > That is completely true for IP traffic.
> >
> > However, the key goal for the simulator level networking is to have
> > these simulated systems be able to talk to other real or simulated
> > systems in all the ways that they did when they were natively
> > networking.  When these systems were in their prime, IP was not the
> > dominant networking protocol.
> >
> > These systems spoke DECnet, LAT, SCS(Vax Cluster Communications),
> etc.
> > All of these protocols were designed around communications on a LAN.
> > The 0readme_ethernet.txt document's goal is to try and get a
> simulator
> > to BOTH be able to participate with these protocols on the local LAN
> > AND to have the host system be able to also communicate with the host
> > System with whatever protocols they may actually share (usually only
> > IP these days).
> >
> > In the earliest days of simh networking, the only strategy we could
> > come up with which would achieve the full networking goal was to
> > install an additional NIC in the hosting system which was dedicated
> to
> > the simh instance and connect that NIC to the same LAN as the primary
> > host NIC.  The host's network stack would be configured to not use
> > this additional NIC for anything and things would work just fine.
> > This strategy was one which also worked for essentially any host
> > platform.
> >
> > Meanwhile, many folks either had host systems which couldn't easily
> > accommodate the addition of additional NICs or they merely wanted to
> > come up with ways to achieve the full set of goals without the
> > addition of extra hardware.  The current simh networking document
> > (0readme_ethernet.txt) describes how these combined goals can be
> > achieved in various host specific ways.  On Linux the bridging
> > approach achieves this functionality.  On Windows, the native stack
> > (combined with some extra code in sim_ether.c) can achieve the goal
> > Without any extra hardware or any special host configuration steps.
> >
> > If your only goal as to use IP to communicate between a simulator and
> > other places (including the hosting system), then your recipe will be
> > sufficient.  I'm not sure how well it would achieve this goal if you
> > happened to want to run multiple simulators on the same host.  The
> > bridging recipe works for this extended case as well.
> >
> > - Mark Pizzolato
> >
> >
> >
> >
>