Networking VAX OpenVMS on SIMH & the Raspberry Pi

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

PiDP

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.

Configuring OpenVMS

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:

$ @sys$system:shutdown

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

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?

 

3 thoughts on “Networking VAX OpenVMS on SIMH & the Raspberry Pi

  1. Kurt Hamm

    I am also having trouble telnetting to the vax. Everything seems to work (ping), but can’t telnet into vax.

    Let me know if you figured anything out with yours. Great info here. I was never able to get this far with vax tcpip until I found your site.

    Kurt

    Reply
  2. Gorazd Kikelj

    I try this setup for network and it works, but there is a problem with interfering with dhcpcd daemon on Raspberrian. I solve this problem with defining IP address for bridge interface br0 in /etc/dhcpcd.conf file and deny configuraion of interfaces tap0 tap1 and eth0 in the same file. I also remove all IP addresses from /etc/networking/interfaces file.

    Additional caveat with dhcpcd is that all ifaces lines need to be “manual” else dhcpcd will abort.

    Reply
  3. Gorazd Kikelj

    Just some additional info on configuration of network interfaces:

    ———————————————
    /etc/dhcpcd.conf

    denyinterfaces eth0 tap0 tap1 tap2 tap3 tap4 tap5 tap6
    interface br0
    static ip_address=/24
    static routers=
    static domain_name_servers=8.8.8.8 8.8.4.4

    profile static_br0
    static ip_address=/24
    static routers=
    static domain_name_servers=8.8.8.8 8.8.4.4

    fallback static_br0
    ———————————————-

    /etc/network/interfaces

    auto eth0
    iface eth0 inet manual

    auto tap0
    iface tap0 inet manual
    pre-up tunctl -t tap0 -u pi
    up ifconfig tap0 up
    down ifconfig tap0 down

    auto tap1
    iface tap1 inet manual
    pre-up tunctl -t tap1 -u pi
    up ifconfig tap1 up
    down ifconfig tap1 down
    … up to tap6

    auto br0
    iface br0 inet manual
    pre-up ifconfig tap0 up
    pre-up ifconfig tap1 up
    pre-up ifconfig tap2 up
    pre-up ifconfig tap3 up
    pre-up ifconfig tap4 up
    pre-up ifconfig tap5 up
    pre-up ifconfig tap6 up
    bridge_ports eth0 tap0 tap1 tap2 tap3 tap4 tap5 tap6
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 2
    ——————————————–
    It should work also without pre-up lines, but didn’t yet test it extensivelly. In limited test it was working ok on latest Raspberian version.

    ——————————————–
    I created three VAX instances and put them into the cluster.
    View of Cluster from system ID 4062 node: PI 21-JAN-2017 08:42:10
    ┌───────────────────┬────────┐
    │ SYSTEMS │ MEMBERS │
    ├──────────┬────────┼────────┤
    │ NODE │ SOFTWARE │ STATUS │
    ├──────────┼────────┼────────┤
    │ PI │ VMS V7.3 │ MEMBER │
    │ OMAN │ VMS V7.3 │ MEMBER │
    │ REPUH │ VMS V7.3 │ MEMBER │
    └──────────┴────────┴────────┘

    vax_pi.ini

    ; Load CPU microcode
    load -r /home/pi/VMS/ka655x.bin
    ;
    ; Attach nvram
    attach nvr /home/pi/VMS/nvram-pi.bin
    ;
    ; CPU 256MB RAM
    set cpu 256m
    ; reduce PI cpu utilization when idle loop is running
    set cpu idle=VMS
    ; break into console
    set cpu CONHALT
    ;
    ; Enable used devices
    set rqb enable
    set rqc enable
    set rqd enable
    set xq enable
    set xqb enable
    ;
    ; Define disk drives PI – attahing here a bunch of disks
    ; $SYS
    set rq0 ra92
    attach rq0 /home/pi/VMS/SYS.DSK
    ;

    ; CDROM
    ;set rqxx cdrom
    ;attach rqxx /dev/cdrom
    ;
    ; Disable unused devices
    ;
    set rl disable
    set ts disable
    ;
    ; Network
    ;
    set xq mac=YY-YY-YY-YY-YY-YY
    attach xq tap:tap1
    set xqb mac=XX-XX-XX-XX-XX-XX
    attach xqb tap:tap4
    ;
    boot cpu

    Reply

Leave a Reply to Gorazd Kikelj Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.