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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
