I just wanted to comment that the instructions for networking in
00readme_ethernet can be simplified for linux. The bridge utilities are
not really necessary after using tunctl, unless you need to do something
more complex.
On a ubuntu oneiric system, I was able to use just the commands listed
in the tunctl man page.
On that system, the commands I used were:
#/usr/sbin/tunctl -t tap0 -u username
# ifconfig tap0 192.168.0.254 up
# route add -host 192.168.0.253 dev tap0
# bash -c 'echo 1> /proc/sys/net/ipv4/conf/tap0/proxy_arp'
# arp -Ds 192.168.0.253 wlan3 pub
(if hardwired. use eth0 in place of wlan3 )
$ Run simulator and "attach xq tap:tap0" ;
finally, on pdp11 (or vax) Unix:
ifconfig qe0192.168.0.253 netmask ... broadcast ...
etc . . .
There was one surprise, however.
Without one more command, I lost the ability to reach the outside world.
The fix was adding this command:
route delete -net 192.168.0/24 gw 0.0.0.0 dev tap0
which unmasked normal default routing through the ethernet interface.
After that, the emulated system and the host were both able to see each
other, and both could access the outside world.
Apparently, the commands I took from the man page resulted in an unspecified
route add -net 192.168.0/24 gw 0.0.0.0 dev tap0
being seen as having been implied by the man page's "route add -host
..." command
The result was that *all* packets on the host that were destined for the
network 192.168.0/24 were being sent to my simulator through tap0 rather
than to my router through my usual interface.
If I had made the simulator be on a different network, I don't think
that would have been a problem. Only the man page does not tell you
any of that, and while the man page's example shows both sides of the
tunnel being on the same network, it leaves it unspecified as to whether
or not the host is on the same network as the tunnel.
- Michael
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
