The DECnet-Linux Experience: It Works!

Ubuntu 14.04 Linux Twins FEDACH (1.553) and FOMFOR (1.554) Talk over DECnet

I was aware of an implementation of the DECnet Phase IV network protocol on the Linux kernel for quite a while now, and recently decided to take the plunge and give it a shot, with additional motivation from this inspiring Retrocomp post.

It was not going well initially because of a bad call I made to try to install ancient releases of Linux distributions from Debian and Fedora from around the time DECnet-Linux was first announced. As a result, I spent many sleepless nights trying to find the packages and dependencies for Linux distros featuring DECnet from the first few years of the new millennium.

Eventually I did what I should have started off with: check if modern Linux distributions still include DECnet-Linux. A search of the kernel of the bleeding-edge Ubuntu 17 "Zesty Zapus" looked promising; DECnet-Linux was indeed compiled right into Ubuntu 17's mainline 4.10 kernel build and the required libdnet, dnet-common and dnprogs packages were available for Ubuntu 17.

Unfortunately, Ubuntu 17's support for DECnet-Linux turned out to be dysfunctional. I created two virtual machines with Ubuntu 17 and installed the DECnet tools, but could not get any farther than the dneigh command showing the other node. FAL, Phone, sethost, etc. would simply not work and would sometimes lock up the virtual machines.

Frustrated, I posted the question to the fabulous folks at the comp.os.vms newgroup. Within a day, I had a path forward; it was clear from John E. Malmberg and "hb" that I needed to try Ubuntu 14.04 or earlier; DECnet-Linux was definitely broken after Ubuntu 14.04.

Re-energized, I proceeded to install the 32-bit release of Ubuntu 14.04.5 LTS (Trusty Tahr) on two virtual machines using the lightweight lubuntu flavor from the Desktop ISO CD image. Then apt-get install dnprogs brought in everything I needed to get DECnet-linux mostly up (the official Ubuntu 14 repositories still work at the time of writing, no need to look for mysterious archives of no-longer supported releases yet.)

However, I still had to make a couple of little tweaks to have DECnet-Linux work all the way. Here are the things I did over and after the default install of DECnet-Linux from Ubuntu 14.04 repositories.

1. The official dnprogs and family of packages from Ubuntu 14.04 repos installed versions of /usr/sbin/dnetnml and /usr/sbin/ctermd that did not work well. The dnetnml program was not responding correctly by showing executor, line, or circuit etc. characteristics when requested by other nodes. Also, attempts to SET HOST from other nodes resulted in the official ctermd program to look for a non-existent local "pty" device and fail.

To get around these problems, I downloaded the source code tarball dnprogs_2.62.tar.gz which is available in practically all Ubuntu 14 mirrors including here. I then built the entire DECnet program suite locally, and then replaced the /usr/sbin/dnetnml and /usr/sbin/ctermd binaries with the ones built locally from source.

2. The official dnprogs installation was not filling in the correct DECnet node-name and address in the files /proc/sys/net/decnet/node_name and /proc/sys/net/decnet/node_address; these file always had "???" and 0.0 despite the correct DECnet executor address being defined in /etc/decnet.conf configuration file. This was resulting in some strange behavior indicating DECnet/Linux was not using the adjacent router node to reach nodes outside the local network, but trying to access them directly and failing. I added simple commands in the /etc/rc.local file (and made it executable and exit with 0) to force the correct DECnet node-name and DECnet address:

# -- rc.local DECnet kludge - /proc/sys/net/decnet/node_name has ???; force it

echo FOMFOR > /proc/sys/net/decnet/node_name

# -- rc.local DECnet kludge - /proc/sys/net/decnet/node_address has 0.0; force it

echo 1.554 > /proc/sys/net/decnet/node_address

# --

3. In an attempt to control "DECnet event 4.3, oversized packet loss" errors when accessing the FAL server on DECnet-linux from remote nodes, I forced the MTU of the DECnet NIC (eth1 in my case) to 576 by adding "mtu 576" to /etc/network/interfaces. I am not sure this actually helps in controlling the error. Here are the corresponding sections of /etc/network/interfaces:

FEDACH

# DECnet 1.553
auto eth1
iface eth1 inet manual
    # MAC address corresponding to DECnet Address
    hwaddress ether aa:00:04:00:29:06
    # Brave attempt to avoid sporadic errors on router node like the following:
    # "DECnet event 4.3, oversized packet loss"
    mtu 576

FOMFOR

# DECnet 1.554
auto eth1
iface eth1 inet manual
    # MAC address corresponding to DECnet Address
    hwaddress ether aa:00:04:00:2a:06
    # Brave attempt to avoid sporadic errors on router node like the following:
    # "DECnet event 4.3, oversized packet loss"
    mtu 576

My two Ubuntu 14.04 virtual machines are named FEDACH and FOMFOR after the twin sons of Macha, daughter of Aodh Ruad. FEDACH has a DECnet address of 1.553 and FOMFOR has 1.554. They are now both connected to HECnet - the global hobbyist DECnet. They are configured to use DECnet on the eth1 network adapter (eth0 is dedicated to IP); the eth1 adapter has the correct MAC address corresponding to the DECnet address as required by DECnet:

1.553 => aa:00:04:00:29:06
1.554 => aa:00:04:00:2a:06

You can quickly look up the MAC address as well as the SCSSYSTEMID SYSGEN parameter for OpenVMS systems corresponding to a DECnet address using my free online DECnet - MAC address - SCSSYSTEMID Calculator.

Also, as DECnet uses all available NICs by default, I modified /etc/default/decnet to have DECnet on eth1 only, and increase verbosity of logging by the dnetd daemon. In addition, I modified the /etc/decnet.conf and /etc/decnet.proxy files as recommended by DECnet-linux documentation and man pages. Here is the output of "ip address show" for eth1 on the two nodes:

FEDACH

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:00:04:00:29:06 brd ff:ff:ff:ff:ff:ff
    dnet 1.553 peer 1.553/16 scope global eth1

FOMFOR

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:00:04:00:2a:06 brd ff:ff:ff:ff:ff:ff
    dnet 1.554 peer 1.554/16 scope global eth1

I created a "decnet" user account for FAL etc. to use by default as configured in /etc/decnet.proxy and the DECnet objects in /etc/dnetd.conf; interactive logins are disabled for this "decnet" account.

Lastly, I wanted the mail system to use the "decnet" account as well instead of the default (and non-existent) "vmsmail" account and created the file /etc/vmsmail.conf with a single line:

username=decnet

Usual DECnet network access commands all work from an external OpenVMS VAX 7.3 Node:

$ MC NCP TELL FEDACH SHOW EXECUTOR CHAR


Node Volatile Characteristics as of 25-SEP-2017 00:32:23

Executor node = 1.553 (FEDACH)

Circuit                  = eth1
State                    = on
Identification           = DECnet for Linux V3.13.0-129-generic on i686


$ DIR FEDACH::

Directory FEDACH::HOME:[DECNET]

DECNET-BUILD.TGZ;1  DECNET.TXT;1        INFO.TXT;1

Total of 3 files.
$ SET HOST FEDACH::
CTERM Version 1.0.6
DECnet for Linux

fedach login:

Mail also works from VMS to Linux over DECnet.

$ MAIL/SUBJECT="TEST MAIL FROM OPENVMS VAX TO UBUNTU DECNET-LINUX" X.COM FEDACH::ROOT

Produces these syslog entries on FEDACH showing mail delivery success:

Sep 29 10:20:46 fedach dnetd[1211]: Connection from: qcocal::sanyal
Sep 29 10:20:46 fedach dnetd[1211]: using user decnet from dnetd.conf
Sep 29 10:20:46 fedach dnetd[2108]: Starting daemon 'vmsmaild'
Sep 29 10:20:46 fedach vmsmaild[2108]: got local user: ROOT
Sep 29 10:20:46 fedach vmsmaild[2108]: Forwarding mail from qcocal::SANYAL       to root
Sep 29 10:20:46 fedach dnetd[1211]: Reaped child process 2108
Sep 29 10:20:46 fedach postfix/pickup[1351]: 8927E6CAB7: uid=1001 from=<decnet>
Sep 29 10:20:46 fedach postfix/cleanup[2112]: 8927E6CAB7: message-id=<20170929142046.8927E6CAB7@fedach.sanyalnet.lan>
Sep 29 10:20:46 fedach postfix/qmgr[1352]: 8927E6CAB7: from=<decnet@fedach.sanyalnet.lan>, size=1029, nrcpt=1 (queue active)
Sep 29 10:20:46 fedach postfix/local[2114]: 8927E6CAB7: to=<root@fedach.sanyalnet.lan>, orig_to=<root>, relay=local, delay=0.16, delays=0.06/0.1/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Sep 29 10:20:46 fedach postfix/qmgr[1352]: 8927E6CAB7: removed

DOWNLOADS

The DECnet-Linux configuration files for my two nodes along with the Ubuntu 14 CD ISO and dnprogs_2.62.tar.gz source files and binaries built on my nodes are available from my google drive here.

CONFIGURATION FILES

/etc/dnetd.conf (Identical for FEDACH and FOMFOR)

/etc/decnet.proxy (Identical for FEDACH and FOMFOR)

/etc/default/decnet (Identical for FEDACH and FOMFOR)

/etc/decnet.conf (FEDACH)

/etc/decnet.conf (FOMFOR)

-x-