[Simh] Using TAP/TUN

[Michael Bloom]

I previously sent a reply to the original message (below), but used only 
"reply" (oops), not "reply all," so it did not go to the list.

It was too long anyway, but the major jist was that the bridge calls 
will not attach a wireless lan card to a bridge, at least under linux 
3.0.0 (the successor to linux 2.6.n).  They return EOPNOTSUPP. So some 
other means is necessary to gate a simulated network of SIMH systems to 
the real world.

Perhaps a sufficient workaround might be for one of the "machines" on 
the simulated network to have two NICS, (one of which is just tunnelled 
to the host) and do routing on that "machine" between the nic on the 
simulated network and the merely tunnelled nic.

As things stand now, however, at least with linux version 3, the 
simulated lan seemingly cannot be merged with a wireless lan via bridging.

- Michael

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