[Update 10/03/2017: some broken links were fixed]
We’ve already had some fun getting a VAX up and running with OpenVMS under SIMH on a Raspberry Pi. And boy, what a mouthful that is. I’m building my installation on my lovely PiDP just because it seems appropriately retro.
I mentioned at the time that the next step would be getting networking working. And now it is (sort of) — and it’s easier than it’s ever been thanks to the latest, greatest version of SIMH. With SIMH 4.0 Beta, there’s no need to use USE_NETWORKING=1 when compiling machines, provided you have libpcap installed.
(By the way, all this assumes a *nix platform — Linux and OS X are what I use.)
The instructions we followed to install and configure the VAX with OpenVMS were those of Phillip Wherry. And although they were written and posted in 2004, they remain the best source material for anyone trying to do this.
But while they are specific to running VAX/OpenVMS under SIMH, they’re not about doing so on a Raspberry Pi. So, in my post there were some digressions and I stopped short of the networking bit. That’s because I knew I was going to have to do some experimenting. And I was right.
Here, I’m going to assume a few things:
- That you have the Wherry page open in your browser and will use that for most of the instructions.
- That you have read my previous post.
- That you have followed Wherry’s instructions up to, but not including, the section headed Configuring OpenVMS.
Setting up the Raspberry Pi
Before we continue with the Wherry process, we need to configure the Raspberry Pi a little. That’s because, while Wherry simply uses the machine’s eth0 Ethernet port for the OpenVMS installation, we’re going to use bridging.
There’s information about this in the SIMH 4.0 beta package. There’s a file called 0readme_ethernet.txt which basically tells you what you need to know. However, there’s a couple of spots in which it’s not exactly clear. And while it provides a shell script for setting up the bridging, I didn’t want to have to run that each time. As I’m using the PiDP machine as my SIMH box, I figured I want the bridging to be persistent.
First, we need to install a few things. My RPi’s host name is pidp and I’ve created the user vax, which is why the prompt you see below is the way it is.
vax@pidp:~$ sudo apt-get install make vax@pidp:~$ sudo apt-get install libpcap-dev vax@pidp:~$ sudo apt-get install bridge-utils vax@pidp:~$ sudo apt-get install uml-utilities
Actually, make is almost certainly installed already if you’re using Raspbian (I’m using Wheezy). And I did mention that you need to have libpcap-dev installed before building your SIMH machines. But I’ve included them here for completeness.
Now let’s talk about your network. Or rather, my network. At home, I use 10.x.x.x. Why do I use a Class A network? Some people would tell you it’s because I have so many Raspberry Pi and BeagleBone boards, not to mention laptops, desktops, phones and tablets that the more conventional 192.168.x.x Class C network simply won’t hack it. Those people are probably my wife. But they’re wrong. It’s to save typing. Seriously.
So anyway, at some point in configuring OpenVMS you’re going to be asked for addresses for the interface, the gateway and the BIND server. You’ll also provide network mask and broadcast addresses. The values I use are:
Raspberry Pi: 10.0.0.58 – this is going to be the address of the bridge interface and so is the address the Pi will use on the network. It used to be the address I gave to eth0 on the Pi, before setting up bridging.
Open VMS interface: 10.0.0.148 – a value I know is not in use anywhere else on the network
Gateway: 10.0.0.1 – that’s my home router
BIND: 10.0.0.1 – as per the gateway
We’ll deal with the other stuff later. I just mention them here because it explains why there are certain values in the forthcoming configurations and why your values might differ.
Now let’s edit the /etc/network/interfaces file to set up bridging persistently. This is my file:
auto lo iface lo inet loopback iface eth0 inet manual # Virtual interface auto tap0 iface tap0 inet manual pre-up tunctl -t tap0 -u vax up ifconfig tap0 10.0.0.148 up down ifconfig tap0 down # Virtual interface auto tap1 iface tap1 inet manual pre-up tunctl -t tap1 -u vax up ifconfig tap1 10.0.0.149 up down ifconfig tap1 down # Bridge interface auto br0 iface br0 inet static address 10.0.0.58 netmask 255.255.255.0 network 10.10.0.0 broadcast 10.0.0.255 gateway 10.0.0.1 bridge_ports eth0 tap0 tap1 bridge_stp off bridge_maxwait 5
I’ve actually set up two virtual interfaces — tap0 and tap1 — because, why not? But we’re really only concerned with tap0 here. You’ll also note that I’ve given these interfaces static IP addresses — 10.0.0.148 in the case of tap0. Few of the references I found online mentioned doing this, but I couldn’t get it to work without doing it. Use your preferred addresses for the tap<n> interfaces and the br0 interface. Also note the line:
pre-up tunctl -t tap0 -u vax
The ‘-u vax’ is a reference to the user. Insert the username you’re using on the Raspberry Pi in place of ‘vax’ here. After you’ve done all this, you’ll want to restart networking. The surest way of doing this is by rebooting the RPi.
Configuring the VAX
Now we need to configure the VAX. In my earlier post, one of the differences from Wherry’s instructions was that I edited the SIMH initialisation file (which I called openvms.ini rather than vax.ini) to disable the networking part. In that post, the networking bit looks like this:
; NOT CONCERNING MYSELF WITH NETWORKING JUST YET ; Attach Ethernet to a network interface ; set xq mac=08-00-2B-AA-BB-CC ; attach xq eth0
We’re now going to change that to use the tap0 interface. The important lines become:
set xq mac=DE-AD-BE-EF-00-00 attach xq tap:tap0
The MAC address is arbitrary — choose one that pleases you, so long as you use only hex numbers (0-9 and A-F). Note that the leading semi-colons have been removed.
You can now boot the VAX and log in as SYSTEM.
At this point, you can continue following Wherry’s instructions. He shows how you set up a user on the system — I created one called ‘admin’ with all privileges. One thing to bear in mind is that whenever you log back in as such a user you probably need to use the following command to ensure you have the necessary rights to edit files and change settings:
$ set proc/priv=all
Follow the Wherry instructions closely to install TCP/IP on the VAX. At one point you issue the command @sys$manager:tcpip$config to enter the menu-driven TCP/IP configuration. Start with entering 1 for the ‘Core environment’ settings, I used mon.local as my domain, because that’s what I use for my local network. I’m not anticipating that this OpenVMS installation is ever going to be exposed to the Internet. When configuring the interfaces, the FQDN becomes vax.mon.local and I entered the address as 10.0.0.148 — the address used by the tap0 interface. OpenVMS will make intelligent guesses for the network mask and broadcast address: with a 10.0.0.0 network, it will assume 255.0.0.0 and 10.255.255.255 respectively.
In the routing section, I went for NO in answer to whether I wanted to configure dynamic ROUTED or GATED and have 10.0.0.1 for the default gateway. When it asked for a default gateway host name I just hit <return>. Under the BIND settings I did the same.
Then I pressed ‘e’ to get back to the top-level menu. From there, I selected 2 to get to the client components, and selected both FTP and Telnet, to get them started (strangely, you start up the Telnet server from the client components menu). Then ‘e’ again to get back to the beginning and select 6 to get things started.
Wherry mentions adding a command to the startup file to ensure TCP/IP gets started on boot. Once you’ve quit the TCP/IP setup and are back at your main prompt, use:
$ set term/vt100 $ edit sys$manager:systartup_vms.com
This drops you into the editor. Scroll down to the bottom. (If the file’s empty, you’ve probably typed an extra ‘s’ — sysstartup instead of systartup: OpenVMS frequently drops the second ‘s’ from ‘sys’ if the rest of the command starts with an ‘s’). If you followed the Wherry instructions to the letter, you’ll have edited the file before, to mount the dua1 and dua2 drives. Add a line to start TCP/IP just before the EXIT line. The last few lines of my file look like this:
$ mount/system dua1 data1 $ mount/system dua2 data2 $ @sys$startup:tcpip$startup $ EXIT [End of file]
Hit Ctrl-Z to save and exit. Now shut down the VAX:
And then boot back in. You should see, close to the end of the boot process, messages about FTP and Telnet services starting up. Once logged in, try pinging Google using TCPIP PING 220.127.116.11.
And confirm that BIND and DNS resolution are working by pinging google.com:
You should also be able to telnet in to your VAX. For some reason, when using telnet to connect from my Mac (hostname zola), I need to specify the port as 23, even though that is the default:
steve@Zola:~$ telnet 10.0.0.148 23
Alas, all is not well in the OpenVMS garden.
SHOW NETWORK/FUL “TCP/IP” gives you some useful information. I’m intrigued that the above information shows nothing for the interface. The TCP/IP configuration utility doesn’t reveal any obvious problem.
And I can ping out, so the interface is clearly working. However, telnetting in seems to be a hit & miss affair. Somedays it works, others it doesn’t, with the connection being refused. The TCP/IP configuration shows the server started.
I suspect a SIMH issue here. Any suggestions would be welcome.
[EDIT] Hmmm, so I rationalised the LAN setup a bit on my router. Restarted the RPi and booted again into OpenVMS. Tried telnetting in from another machine on the network …. connection refused. Then, in the OpenVMS session I pinged out. Tried telnetting in again … worked! So is this something to do with the tap0 virtual device? It feels like it’s not being properly brought up until the first time it’s used. And yet, before running SIMH/OpenVMS, ifconfig on the Raspberry Pi shows br0, tap0 and tap1 all UP and with the right IP addresses.
[EDIT 2] So I edited the RPi’s /etc/network/interfaces and added pre-up commands for the bridge interface br0:
# Bridge interface auto br0 iface br0 inet static pre-up ifconfig tap0 up pre-up ifconfig tap1 up address 10.0.0.58 netmask 255.255.255.0 network 10.10.0.0 broadcast 10.0.0.255 gateway 10.0.0.1 bridge_ports eth0 tap0 tap1 bridge_stp off bridge_maxwait 5
Rebooted the Pi, restarted VAX OpenVMS, and even without logging in to the OpenVMS session I could telnet in from another machine. Coincidence?