OpenVMS networking setup
This guide will show you how to setup networking inside AXPbox with OpenVMS. Due to how the emulator works, it requires a rather special setup if you run on Linux and have only one network interface. The guide has a few parts, we'll start off with a bit more detail on why this special setup is required and how to configure it, then we'll do the actual network setup inside OpenVMS.
We assume you have compiled AXPbox and have installed OpenVMS inside it.
- This wiki has a guide on how to install OpenVMS
- There is an article covering compilation and setup, including networking, on Remy's blog.
The first two topics of this guide are the AXPbox configuration and the OpenVMS setup. These are the same, regardless of the networking setup you have. If you are on Linux and have 1 NIC, you should read the VirtualBox setup first (see below) if you want guest-to-host communication to work. Also in some cases networking doesn't work on a specific kind of interface (e.g. wireless) - if that happens, you may also get around the issue by using a VirtualBox setup. If you have multiple NICs or use Windows, this shouldn't be needed.
Inside es40.cfg you need to configure your interface:
pci0.4 = dec21143
{
adapter = "enp0s3"
mac = "08-00-DE-AD-BE-EF";
}
The MAC parameter is optional, but if you are running multiple AXPbox
instances to play with clustering, we recommend you change it to something
other than the default. Change en0ps3 to your network adapter, you can find
it with the ifconfig or ip addr command.
On modern Linux systems, you need to give the emulator special permissions for networking:
sudo setcap cap_net_raw,cap_net_bind_service=+eip ./axpbox
If you still get a permission error afterwards, start the emulator as root
(sudo ./axpbox run).
Login as the SYSTEM user (or elevate your permissions, SET PROCESS/PRIVILEGE=SYSPRV) and issue the following command to open the
interactive menu driven configuration for TCP/IP:
@SYS$STARTUP:TCPIP$CONFIG.COM
In my setup, the IP and subnet for OpenVMS will be 10.0.2.25/24,
the gateway will be 10.0.2.2 and DNS is 8.8.8.8. In the below commands,
replace those for your network.
On VSI OpenVMS the output is a bit different than on HP OpenVMS the first time, you should be able to follow along with both. First is a warning that not everything is setup yet:
TCP/IP Network Configuration Procedure
This procedure helps you define the parameters required
to run HP TCP/IP Services for OpenVMS on this system.
Checking TCP/IP Services for OpenVMS configuration database files.
Creating SYS$COMMON:[SYSEXE]TCPIP$SERVICE.DAT
Creating SYS$COMMON:[SYSEXE]TCPIP$HOST.DAT
Creating SYS$COMMON:[SYSEXE]TCPIP$NETWORK.DAT
Creating SYS$COMMON:[SYSEXE]TCPIP$ROUTE.DAT
Creating SYS$COMMON:[SYSEXE]TCPIP$PROXY.DAT
Creating SYS$COMMON:[SYSEXE]TCPIP$CONFIGURATION.DAT
Node: U1
HP TCP/IP Services for OpenVMS requires either DHCP to be
configured or alternately, you must manually configure an
address, and a hostname. HP TCP/IP Services for OpenVMS
will not start until these are configured.
DHCP - NOT configured.
Hostname - NOT configured.
Please configure these from the Core Environment Menu on node U1.
Press Return to continue.
The next menu lists the possible choices. We'll start with 1, the Core Environment:
HP TCP/IP Services for OpenVMS Configuration Menu
Configuration options:
1 - Core environment
2 - Client components
3 - Server components
4 - Optional components
5 - Shutdown HP TCP/IP Services for OpenVMS
6 - Startup HP TCP/IP Services for OpenVMS
7 - Run tests
A - Configure options 1 - 4
[E] - Exit configuration procedure
Enter configuration option:
If you see license errors, like below:
2 - Client components No Client License
3 - Server components No Client License
[...]
1 - Domain No Client License
3 - Routing No Client License
4 - BIND Resolver No Client License
Those mean your hobbyist license wasn't installed correctly. Reboot and retry.
Start with option 2, Interfaces:
HP TCP/IP Services for OpenVMS Core Environment Configuration Menu
Configuration options:
1 - Domain
2 - Interfaces
3 - Routing
4 - BIND Resolver
5 - Time Zone
A - Configure options 1 - 5
[E] - Exit menu
Enter configuration option: 2
Next pick the only interface, WE0:
HP TCP/IP Services for OpenVMS Interface WE0 Configuration Menu (Node: U1)
Configuration options:
1 - Add a primary address on WE0
2 - Add an alias address on WE0
3 - Enable DHCP client to manage address on WE0
[E] - Exit menu
Enter configuration option: 1
Pick 1 to configure an IP address:
* Is this address used by Clusters over IP (IPCI) [NO]:
IPv4 Address may be entered with CIDR bits suffix.
E.g. For a 16-bit netmask enter 10.0.1.1/16
Enter IPv4 Address []: 10.0.2.25/24
Enter hostname []: u1.home
Requested configuration:
Node : U1
Interface: WE0
IPCI : No
Address : 10.0.2.25/24
Netmask : 255.255.255.0 (CIDR bits: 24)
Hostname : u1.home
* Is this correct [YES]:
Exit the next menu with E:
HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu
Hostname Details: Configured=u1.home, Active=u1
Configuration options:
0 - Set The Target Node (Current Node: U1)
1 - WE0 Menu (EWA0: TwistedPair 100mbps)
2 - 10.0.2.25/24 u1.home Configured
[E] - Exit menu
Enter configuration option: E
Select option 3 - Routing and answer NO to the first question:
DYNAMIC ROUTING Configuration
[...]
* Do you want to configure dynamic ROUTED or GATED routing [NO]:
Enter the hostname of your gateway, or it's IP address:
A default route has not been configured.
* Do you want to configure a default route [YES]:
Enter your Default Gateway host name or address: 10.0.0.1
You'll be back in the previous menu. Select 4 for the DNS resolver configuration:
BIND RESOLVER Configuration
A BIND resolver has not been configured.
HP TCP/IP Services for OpenVMS supports the Berkeley Internet Name
Domain (BIND) resolver. BIND is a network service that enables clients
to name resources or objects and share information with other objects
on the network.
Before configuring your system as a BIND resolver, you should
first be sure that there is at least one system on the network
configured as either a BIND primary or secondary server for
this domain.
You can specify a BIND server by its address or name;
however, if specified by name, an entry for it must
exist in the TCPIP$HOST database.
You will be asked one question for each server.
Press Return at the prompt to terminate the list.
Enter the address of your DNS server, in our case it's Google DNS:
Enter your BIND server name: 8.8.8.8
8.8.8.8 is not in the local host database.
If you want to enter the server in the local host
database, enter the server name. Otherwise, enter <CR>.
Give it a name:
Enter remote BIND server name []: googledns
Enter nothing here, just return:
Enter next BIND server name:
Creating file TCPIP$ETC:IPNODES.DAT
Creating file TCPIP$ETC:SERVICES.DAT
Creating file TCPIP$ETC:RESOLV_CONF.TEMPLATE
You must provide the domain name in order to run
the BIND resolver. This information should be available
from your Internet network administrator.
You will now be asked to configure the domain name.
Enter a domain name of choice here, I choose local.home.
You'll be back in the main menu, exit that with E to go to the topmost menu.
Select 6 to start the TCP/IP stack:
Enter configuration option: 6
Begin Startup...
%TCPIP-I-INFO, TCP/IP Services startup beginning at 3-NOV-2020 14:26:22.10
%TCPIP-I-INFO, creating UCX compatibility file SYS$COMMON:[SYSEXE]UCX$SERVICE.DAT
[...]
%%%%%%%%%%% OPCOM 3-NOV-2020 14:26:32.85 %%%%%%%%%%%
Message from user INTERnet on U1
%TCPIP-I-FSIPADDRUP, WE0 10.0.2.25 primary active on node U1, interface WE0
[...]
%TCPIP-S-STARTDONE, TCP/IP Services startup completed at 3-NOV-2020 14:26:41.06
IP Configuration is finished! Well done.
Lets test if we can connect to the outside world:
$ tcpip ping 8.8.8.8
Output:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=63 time=169 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=90 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=63 time=46 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=63 time=79 ms
----8.8.8.8 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 46/96/169 ms
Yay! You can view the current information with tcpip show, a few examples:
$ tcpip show int
Packets
Interface IP_Addr Network mask Receive Send MTU
LO0 127.0.0.1 255.0.0.0 0 0 4096
WE0 10.0.2.25 255.255.255.0 5 6 1500
$ tcpip show route
DYNAMIC
Type Destination Gateway
AN 0.0.0.0 10.0.2.2
AN 10.0.2.0/24 10.0.2.25
AH 10.0.2.25 10.0.2.25
AH 127.0.0.1 127.0.0.1
In Remy's guide automatically starting networking at boot, setup of different services (SSH, telnet, FTP) and
the installation of a few network utilities like curl is also covered, so you may follow that if you want advice
on getting some services running.
AXPbox uses libpcap to emulate networking. On Linux, packets made by
AXPbox are not received by the host system. This means that if you run
AXPbox on your desktop, your desktop will not be able to communicate with
AXPbox, but other systems on the network will be. This issue can be resolved
by using 2 network interfaces on your host system (one for AXPbox and one for
regular networking) or by a VirtualBox setup which we'll explain further.
This issue is documented by SIMH, they have the same setup for networking (although, simh also support tun/tap and vde, which do not suffer from this problem).
In the simh docs:
On Windows using the WinPcap interface, the simulated computer can "talk" to the host computer on the same interface. On other platforms with libpcap (linux, mac OS), the simulated computer can not "talk" to the host computer via the selected interface, since simulator transmitted packets are not received by the hosts network stack. The workaround for this is to use a second NIC in the host and connect them both into the same network; then the host and the simulator can communicate over the physical LAN.
And in the SIMH FAQ PDF:
2.11 - My Linux, OSX or other Unix host can't communicate with the PDP-11 or VAX over Ethernet; why?
The network stacks on these systems don’t naturally receive packets which are transmitted with the pcap_sendpacket API.
There may also be issues with bridged interfaces.
Because of the above, if you want to use networking (which you probably will, it's awesome to play with clustering) and have only 1 NIC in your PC, we recommend you use a virtual machine with two separate network adapters. In VirtualBox on Ubuntu 20.04 is used. (If you use libvirt, which adds the host to its NAT network, you can just use the default network interface and it should work fine; if not, follow the steps below to set up a VirtualBox VM).
The Debian 10 virtual machine with has two virtual network adapters,
the first is in the VirtualBox NAT network (that one will be used by
OpenVMS), the second is bridged into the host network (that one is used to SSH into
the Debian VM from Ubuntu).
This Debian 10 VM runs AXPbox, so it's a bit of virtual machine inception going on. Have your spinning top ready.
OpenVMS inside AXPbox can connect to the internet, and via VirtualBox you can create port forwards back into OpenVMS (this is not needed with libvirt). That will be explained later on in the network section, including screenshots.
Important: if you have multiple NICs you can skip the entire VirtualBox setup.
Now when you have a VM set up with two NICs, you need to setup a port forward to be able to reach OpenVMS. OpenVMS can connect to the outside world via NAT, but you cannot get in. Just like your home router allows all your devices to access the internet, but blocks the internet from accessing your devices unless you open a port.
Open up the preferences pane in VirtualBox for the Debian VM, go to the networking page and select the NAT adapter tab. Click Advanced, then Port Forwarding and enter the following, as the image below shows:
- Enter port 2323 as Host port, and 23 as guest port for telnet.
- Enter port 2222 as Host port, and 22 as guest port for SSH.
For both lines, enter the NAT OpenVMS IP, in my case,10.0.2.20.
You can now connect to localhost (or the Debian VM IP) with those ports to reach OpenVMS:
telnet 10.0.0.8 2323 # 10.0.0.8 is my Debian VM IP
Do note that you have to setup the services (see the link to Remy's blog post above for that).
If you decide to setup WASD (web server) you need to open up port 80/443 as well. Inside the NAT network all communication is allowed, so clustering doesn't require any additional ports open.