[Simh] MicroVax 3900 Networking on a Macbook Air

Hittner, David T (IS) david.hittner at ngc.com
Sat Oct 3 10:57:58 EDT 2015


As Johnny pointed out, Wireless Ethernet isn't Ethernet.  Many "Ethernet" principles are discarded or bent to maximize bandwidth over the small wireless spectrum.

To conserve wireless bandwidth, most Wireless routers will only forward wireless IP packets that contain the exact source/destination MAC address of the wireless device that has "registered" with the wireless router.

So if your wireless adapter MAC address is 00:01:02:03:04:05, that's the only address that will be sent over the wireless spectrum.
The virtual VAX by default is 08:00:2b:aa:bb:cc - since it isn't the same as the registered MAC address, the packets usually are ignored and dropped.

At the cost of some poor network performance, you can try setting the VAX's MAC address to be the same as the MAC address of the hardware wireless device (set xq mac=00:01:02:03:04:05).
Assuming that PCAP is allowing promiscuous mode and passing through all packets, they should be transported over the wireless link.
The different IP addresses of the host system and the VAX TCPIP should allow the two systems to sort out who gets which IP packet.

This technique will NOT work with DECNET IV, which has a different packet type - most wireless routers are optimized to only pass IP traffic - DECNET V without compatibility mode works fine. If you manage to find a wireless router and device combination  which passes all packet types, you can reverse the MAC alignment scenario for DECNET and set the MAC of the host device to be the target DECNET address (aa:00:04:xx:yy:zz) of the VAX, and then manually start/stop DECNET on the VAX to deal with the DECNET panic when it sees a duplicate DECNET address on the wire. If you are really careful, it is possible to find wireless routers and devices which will pass all packet types and MAC addresses in "bridge" mode, so you don't have to use the duplicate MAC trick - but they are few and far between, and their performance is generally not as good.

In summary: If you want to use SIMH networking, use a hard wire - wireless is a pain.

Dave

-----Original Message-----
From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Pizzolato - Info Comm
Sent: Saturday, October 03, 2015 5:29 AM
To: Zachary Kline; simh at trailing-edge.com
Subject: EXT :Re: [Simh] MicroVax 3900 Networking on a Macbook Air

On Friday, October 2, 2015 at 5:21 PM, Zachary Kline wrote:
> I was wondering if anybody could give me some tips on networking with 
> my MacBook air. I used to run a virtual VMS system a few years back, 
> but that was on Windows and/or Linux, with access to “real,” ethernet devices.
> I’ve since switched to the wifi-only Macbook Air, and it isn’t 
> cooperating very well. My copy of TCPIP services fails to get a DHCP lease.
> I know that bridging with wifi adaptors is problematic, but I built 
> with the OS X native LibPcap support, and I thought it might help.
> 
> Here is my simh version info
> 
> 	Simulator Framework Capabilities:
> 		64b data
> 		64b addresses
> 		Ethernet Packet transport:PCAP:UDP
> 		Idle/Throttling support is available
> 		Virtual Hard Disk (VHD) support
> 		Asynchronous I/O support
> 		FrontPanel API Version 1
> 	Host Platform:
> 		Compiler: GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-
> 700.0.72)
> 		Simulator Compiled: Sep 30 2015 at 21:53:11
> 		Memory Access: Little Endian
> 		Memory Pointer Size: 64 bits
> 		Large File (>2GB) support
> 		SDL Video support: No Video Support
> 		RegEx support for EXPECT commands
> 		OS clock tick size (time taken by msleep(1)): 2ms
> 		OS: Darwin Zacharys-MacBook-Air.local 15.0.0 Darwin Kernel Version 
> 15.0.0: Tue Sep 22 20:33:10 PDT 2015; root:xnu-
> 3247.10.11.1.1~1/RELEASE_X86_64 x86_64
> 
>         git commit id: c3a879da
> 
> Show xq eth:
> 
> ETH devices:
>  eth0	en0                                  (No description available)
>  eth1	awdl0                                (No description available)
>  eth2	bridge0                              (No description available)
>  eth3	en1                                  (No description available)
>  eth4	udp:sourceport:remotehost:remoteport (Integrated UDP bridge
> support)
> 
> en0 is the wifi adaptor I’m interested in, and bridge0 is an OS 
> X-provided THunderbolt Bridge, which doesn’t seem particularly useful for my purposes.

Johnny's comments and suggestions are right on.  

One way to help get you there might be to use VDE networking. Some folks have used vde for various purposes.  If someone who uses VDE networking provides some guidance we can add more vde specific information to 0readme_ethernet.txt.

- Mark
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh


More information about the Simh mailing list