Sunday, September 24, 2017

The DECnet-Linux Experience: It Works!

Supratim Sanyal's Blog: DECnet Linux Communication Between two Linux nodes
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 address in the file /proc/sys/net/decnet/node_address; this file always had 0.0 despite the correct DECnet executor address being defined in the /etc/decnet.conf configuration file. This was resulting in some strange behavior indicatng Linux-DECnet was not using the adjacent router node to reach nodes outside the local network, but trying to access them directly and failing. I added a simple command in the /etc/rc.local file (and made it executable and exit with 0) to force the correct DECnet address:
# -- 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:


# 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


# 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:


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


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:


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


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




Total of 3 files.
CTERM Version 1.0.6
DECnet for Linux

fedach login:

Mail also works from VMS to Linux over DECnet.


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


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.


/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)



  1. Hi Supratim,

    i'm a new member of the HECnet clan (area 35) and i was just curious - did you ever get DECnet to run on anything newer that Ubuntu 14 and 3.x kernels?

    i'm currently reading and working through a few articles on 4.x kernel, however there isn't much about. DECnet definitely broke in 4.x and there isn't much interest to fix it.

    just curious to see if you'd tried this out with anything more modern. my goal is to see if I can replace my virtual cisco router with native linux routing for Phase IV and the GRE tunnels.

    many thanks,

    cheers, Wiz!!

  2. We might have corresponded in the mailing list later? Even though I haven't experimented with later kernels, but you will find what Erik did at of interest.

    BTW I am running Paul Koning's DECnet/Python on multiple nodes for a while now - it is a complete user-mode implementation of Phase IV and does GRE, MULTINET, Ethernet and more - all in the user-land. You can see examples of what it does at the nodes below (it includes a web server):

    PYRTR (31.3)

    SHAKTI (31.50)

    PYDNET (31.1021) (direct)

    IMPRTR (31.1023)

    I recently installed DECnet/Python on a Hercules-emulated IBM S/390 ... node 31.60 ... its kind of interesting to see IBM talking DECnet :)

  3. thanks for the reply.

    i have already found Erik's site and I'm starting to play with building a modern kernel with his patches. I also found reference to rasbian decnet on github with similar code that i will also play with.

    do you have any references/sites/etc for Paul's decnet/python code? i did some searching around and didn't really find much apart from a subversion server (which i believe is still active).

    i think i'd really like to take DECnet/Python for a spin if you can point me in the right direction.

    many thanks,

    cheers, Wiz!!

  4. We have corresponded elsewhere, but for the sake of others, briefly:

    To obtain Paul Koning's DECnet/Python:

    $ svn co svn://
    $ cd pydecnet/
    $ sudo python3 install # Optional, I run it from the svn directory, not from the install locations

    The three configuration files of most interest are
    - pydecnet.conf
    - http.conf
    - nodenames.conf

    Paul includes great documentation with the distribution.


"SEO" link builders: move on, your spam link will not get posted.

Recommended Products from Amazon