patrick@users.sourceforge.netDECnet was designed by Digital as a way to interconnect their range of products. In its Phase IV implementation, released in 1983, it can support 63 areas of 1023 nodes each. The specifications for DECnet Phase IV are freely available. This has allowed others to provide DECnet connectivity in their products such as Sun's Sunlink DNI, and now of course Linux.
As with TCP/IP there are a number of higher-level protocols layered on top the basic DECnet protocol to provide services to applications. The ones currently available for Linux are DAP (Data Access Protocol, a File transfer protocol analogous to FTP in the TCP/IP world) and CTERM for remote terminal access (analogous to telnet).
DECnet for Linux is only really of use to you if you have OpenVMS machines, or other machines that use DECnet, on your site. There are several TCP/IP stacks for OpenVMS available from Compaq and several third-party vendors. These tend to be quite expensive, particularly when licenced for larger VAX or Alpha machines or clusters with large numbers of workstations.
DECnet is very common in OpenVMS shops because (although licenced separately) it is bundled with OpenVMS. DECnet for Linux allows Linux boxes to participate as end nodes in a DECnet network. Maybe you have a Linux box as part of an OpenVMS to Unix migration plan (poor you!) or maybe it is providing internet services to your company. DECnet for Linux aims to provide you with the tools for Linux to participate in the DECnet network.
In a nutshell, if you have OpenVMS machines and Linux machines at your installation then this software will probably be useful to you. If you've never heard for OpenVMS (or just plain VMS as us old-timers refer to it) then you probably don't need it.
An end-node is a DECnet node that has no routing information. It can only (directly) access other machines in the same DECnet area (like a TCP/IP subnet) as itself. To access nodes in other DECnet areas a DECnet router must be present on the network.
The code is written to conform to the published DECnet phase IV specifications and so should work with any Phase IV node - this means VMS 4.0 and above should work.
In practice I am limited in the versions of VMS available to me. Tramp (the machine in the picture on the web page) runs VMS V5.4 and (thanks to the hobbyist programme) I also have a machine running V7.2 which I use for most of my testing. I reckon that anything above 5.0 should be fine - if anyone has any reports (good or bad) of this software with VMS V4.x I would be interested to know.
I have tested these programs against VAX and Alpha machines running OpenVMS 7.2
In theory it should talk to any machine that runs DECnet phase IV, such as PDP-11s running RSX-11 or RSTS/E or Alpha machines running Compaq(tm) Tru64(tm) Unix(tm). However I only have access to machines running VMS so I can't guarantee anything.
If you try the software to connect to other than VMS systems and have problems then contact me via the list and maybe we can sort the problems out. If you can fix them yourself and send me a patch then that would be greatly appreciated!
The DECnet for Linux home page is at http://linux-decnet.sourceforge.net There you will find all the sources for the kernel as well as several useful applications and utilities. Binaries for the applications are available for Intel, Alpha and SPARC machines, though ports other than Intel may not always be up-to-date, it depends on what hardware I have access to at the time of release.
Just ethernet at the moment. See below for DDCMP (serial lines)
We don't currently support DDCMP but some work is going on (slowly) to add it to the feature list. If you need DDCMP then don't hold your breath it could be a very long time before it works.
If you want to help with the development then please contact me (patrick) via the mailing list and I'll tell you what thoughts I have on the subject.
LAT (Local Area Transport) is a terminal protocol usually used for accessing terminals and printers connected to terminal servers. I originally stated that there were no plans to support it. I lied.
LAT is now available from the DECnet home page and is available in source and binary packages for various architectures. It supports both normal and "reverse" LAT. See the LAT page at http://linux-decnet.sourceforge.net/lat.html for more information.
LAD and LAST are the protocols used for remote disk access, and is most commonly by the InfoServer products and PATHWORKS. Unfortunately Compaq do not publish the specifications for these protocols, nor do I have the hardware or software to test it. Because of this there are no plans to support LAD or LAST.
Yet again, I don't have the specification for DFS or a copy of the software so I can't do anything about it. I'd actually love to do a DFS implementation so if anyone knows how to do this then please let me know.
Hmmm, printing. Another unpublished protocol I'm afraid. Plus I don't have room in my small English house for a large PrintServer (even if I could find or afford one). So this is probably out of bounds too.
If you want to access files on Linux from PCs then Samba is the program for you. There is very little point in using DECnet to communicate from Windows PCs to Linux as both natively support TCP/IP.
Linux can not mount PATHWORKS volumes on a VMS system. If you want access to VMS files from Linux then the dnprogs suite is designed to do just that.
"DECnet-Plus" or "DECnet Phase V" or "DECnet/OSI" has been available in various forms for several years now and is standard with newer releases of OpenVMS. It is backward compatible with Phase IV though you will need Eduardo's kernel patch 0.0.15 (or later) or Steve's 2.4 kernel for it to work.
There is no freely available documentation for the low-level details DECnet plus and there are no plans to support it directly.
Yes you can. You can boot them using mopd (available from the ftp site) provided you have a copy of the boot image and the LAT server sofwtare (also on the ftp and download sites) is now stable. You do not need any other of the DECnet software if all you wish to do is use LAT.
Officially none, but you do get the sources!
I encourage all users to join the linux-decnet-user mailing list by visiting the mailing list page at http://sourceforge.net/mail/?group_id=4993 This way all users can share experiences and help each other. Announcements of all new releases of kernel patches and programs are also made to this list.
If you need help with the software, think you have found a bug or would like to request a feature then please send your messages to this mailing list.
No. The programs I provide rely on the kernel implementation which is Linux specific. Providing DECnet in the kernel of other OSs is a large undertaking and probably only reasonable possible on other open source operating systems such as FreeBSD, NetBSD or OpenBSD.
If someone does provides a DECnet kernel layer for any of these operating systems (and it is largely compatible with the Linux one) then let me know and I'll be happy to port the programs (on platforms I have access to).
Yes, the Linux 2.4 kernel will have DECnet included as standard. It has been included in the development series since early in the 2.3 series.
There are currently two streams of DECnet kernel development. The stable series is the 'Eduardo' patches written by Eduardo Serrat in Argentina. These are for kernels 2.0 and 2.2.
The development series is being done by Steve Whitehouse in England for kernels 2.3 and higher. This code is included in the stock 2.4 Linux kernel.
If you want to use DECnet now on a 2.2 kernel then the Eduardo kernels are the ones to use. if you are using Linux 2.4.0 or greater than DECnet is already included. Note that, currently, the binary packages on the web site are for 'Eduardo' 2.2 kernels and do not work correctly on 2.4, so you will need to build from sources.
Much as I like Linux I have difficulty understanding why you would want to do this. However, there is a project to port Linux to VAX processors (see the web site links page for the URL). It is very incomplete and does not run at the time I write this.
If you want a free Unix to run on a VAX then send me the VAX and I'll give you a 486 PC - it'll be much faster. No, seriously I can recommend NetBSD. It supports quite a large range of VAX hardware and performs well. You can even boot it from a Linux PC using mopd (see above).
It is if you get a hobbyist licence from http://www.montagar.com/hobbyist. You need to be a DECUS member to do this. And, of course you will need a VAX or Alpha machine to run it on !
Why not?
I'm doing it because I think it's fun. I don't have a serious use for this software, I just like getting involved in things to do with VMS and Linux and this project nicely combines the two.
The software available provides quite a full list of DECnet programs. File transfer, terminal access, mail and phone are all available. Your Linux box can now be a very functional DECnet end node.
From VMS, yes. The Linux FAL provides all the functionality of FAL on VMS.
Currently, from Linux, you have to use the dn* programs on Linux to access files
on VMS (ie you can't vi bigvax::login.com for instance).
I have some ideas on how to make this possible though.
You can't do NCB (Network Control Block) programming on Linux and there are no plans to support it as it relies on rather a lot of VMS system services and run-time library functions. Plus, I don't think the demand is very high!
The normal Linux commands can't handle RMS indexed files. Unix has no real concept of them. If you use the dn* programs then they will simply read the files sequentially.
You can write programs to access indexed files though, using librms (see later)
No.
Yes you can. If you want to run X-Windows programs on OpenVMS and display them on linux you can download a DECnet enabled X-Server from http://linux-decnet.sourceforge.net/Xservers.html. If your X-server is not available then you will have to compile it yourself using the instructions at http://linux-decnet.sourceforge.net/x11r6.html. If you are using a commercial X-server then you may be out of luck.
If you want to run Linux applications on a VMS workstation then you will also have to rebuild the libX11 shared library. If you download the complete XFree86 sources rather than just the servers and follow the instructions on the web page, you will also get a complete set of DECnet-enabled libraries. Copy xc/lib/X11/libX11.so.6.3 to /usr/X11R6/lib, restart X-Windows, and off you go.
First make sure you have recompiled libX11 with DECnet support (see above) and that your Linux application is using that library. The syntax for DECnet remote displays is similar to that for TCP/IP remote displays but with a double colon eg: TRISHA::0
If you get the message:
error in loading shared libraries: /usr/X11R6/lib/libX11.so.6.2: undefined symbol: dnet_conn
The other thing you need to do is to set the security options for the display. Using the Style Manager Security applet in CDE add the Linux node name and the user UID number (not name!) you are running the Linux application as. You can also put * as the username to allow all Linux users from that node. Make sure that the Linux node name is known to the local DECnet system.
Linux does not understand the ODS-2 (or ODS-5) filesystems used by VMS but there are some freeware utilities available to read files from VMS disks and CDs that are connected to Linux systems. Here is a URL for the one I use: http://perso.club-internet.fr/lelegard/vmscd.
If you mean "can I read them over the network" well, Eduardo has provided a filesystem called 'dapfs' and there is a dnmount utility in the dnprogs package. Be aware that dnmount is not included in any of the binary distributions and only builds from source if you have applied the dapfs kernel patch.
The dapfs patch for 2.4 kernels is much more reliable than the 2.2 version.
No. VMS does not understand the Linux file format. If you have an NFS server for VMS then you could use that.
FAL should normally be perfectly adequate for the task.
If you want to extend the disk space of a small VAX by using 'spare' space on a Linux box then you could use Eduardo's "Poor Man" series of VMS device drivers. See the web page for more information.
Yes you can. There is a mopd daemon available (I believe it was originally ported from NetBSD) that will service such requests. This software is not part of the DECnet for Linux project so please don't ask me for support on it. See the links page for an up-to-date URL.
The routing functionality is being included in the 2.4 kernels but it is largely untested and there are few or no user-level tools to manipulate the routing tables. If you are interested in routing then please join the mailing list and ask.
Yes you can. FAL on Linux supports PRINT/REMOTE and SUBMIT/REMOTE requests from a VMS system and the dnprogs suite provides dnprint and dnsubmit commands to go the other way.
I keep a FUTURE_PROJECTS file in the dnprogs source distribution that has my latest thoughts on the matter but it's shrinking rapidly.
If you have any bright ideas about applications for DECnet that you would like to see then please mail the list and I'll think about them.
Currently only Intel, Alpha and SPARC have been tested.
I don't have access to other Linux architectures so can't try them. I hope that the issues encountered doing the Alpha and SPARC ports will mean that the others with "just work" but I am not naive enough to believe it will be the case!
If you do try DECnet with other Linux architectures then please let me know.
Contact the mailing list to see what projects are underway to make sure you're not duplicating work. You will probably want to check the various DECnet specifications available at ftp://gatekeeper.dec.com/pub/DEC/DECnet/PhaseIV/index.html
If you have bugs to report or patches to submit please send them to the mailing list or submit them on sourceforge via the project page at http://sourceforge.net/project/?group_id=4993.
If you are serious about contributing code to the project then I will be happy to add you as a sourceforge developer (you will need to get yourself a sourceforge login ID first). This will give you write access to the CVS repository and the bug reporting system.
I tend to do releases when I think I have enough new features or bug-fixes to justify them, so sometimes it means I hang on to fixed bugs longer than some users may like. The current code is kept in the sourceforge CVS system at http://sourceforge.net/cvs/?group_id=4993. You will need to install CVS on your machine to download this but CVS is included with almost all Linux distributions these days. Please read the instructions for using sourceforge CVS carefully.
That's rather a big question! DECnet is implemented in terms of the Berkeley sockets API used for TCP/IP so the same techniques for socket/bind/connect etc apply to DECnet too. There are additional setsockopt calls you may need to call to enable different DECnet features such as authentication.
The other way is to look at some example source code - of which there is ample available in the dnprogs-*.tar.gz source package.
If you want to write a server then I recommend you use the libdnet_daemon library because that simplifies all the messy details of starting a daemon from dnetd and dealing with user authentication and forking. You simply register the daemon and wait to be called. All the daemons provided in the dnprogs package use this library so there are plenty of examples to choose from.
If you want to write a client there are two options. If all you want to do is access files on a VMS system then you should use librms. This library provides applications with high-level read and write functions that access RMS files. You can use indexed files too.
There is also the socket layer if you want to interact with a known DECnet object.
All the executables in the dnprogs package are released under the GNU General Public License(sic), the libraries are released under the GNU Library(or Lesser) Public License(sic).
This basically means that you can use the programs provided they are unmodified and you can use the libraries provided you dynamically link with them. The text of the licences is included in the package (or on the GNU web site) so please read them carefully.
This is a side-effect of GNU autoconf. If you compile an X-windows program on a machine with DECnet on it then it will be dynamically linked with libdnet. This is because GNU autoconf knows that the X-Windows libraries on Ultrix (yes Ultrix, remember that) require it. In fact if you compile X11 with DECnet support then so will yours.
The solution is to recompile on a machine without DECnet (remember to delete config.cache first) or, perhaps easier, to copy libdnet onto those machines. It's quite harmless...really.
Unfortunately IPv6 has defined a new function called getnodebyname which clashes with the DECnet function of the same name. I don't know why they did this because the standard nomenclature for a machine in IP is "host" rather than "node" which is used by DECnet.
The neat way around the problem is to do IP socket manipulation in one file and DECnet in another, thus avoiding the need to include netdb.h and dnetdb.h in the same file. If you can't do this then I suggest the following horrible hack:
#include <features.h>
#if (__GLIBC__ >= 2 && __GLIBC_MINOR__ >= 1) || __GLIBC__ >= 3
#define getnodebyname ipv6_getnodebyname
#endif
#include <netdb.h>
#if (__GLIBC__ >= 2 && __GLIBC_MINOR__ >= 1) || __GLIBC__ >= 3
#undef getnodebyname
#endif
If you need to actually use the IPv6 function then it gets much harder and I don't have an immediate answer. Linking against libdnet will supercede the libc getnodebyname with the DECnet one.
I am reluctant to change the name of this function because it breaks X11, Ultrix compatibility and existing DECnet programs but if it becomes a nuisance I may bow to pressure. I would also welcome any suggestions on this matter
This is a warning issued by GCC in an attempt to stop people coding Y2K bugs. Unfortunately the DAP protocol as defined by Digital uses two digit dates when transmitting file dates so I have to comply.
Please ignore this warning.
DECnet uses the MAC(hardware) address to route messages between nodes. This effectively does away with the ARP protocol used by TCP/IP to map IP address to hardware addresses.
For most ethernet cards you will therefore have to change the card's hardware address so that it can pick up DECnet requests sent to it. (The DEC tulip chip does not need this. If you are using the tulip or de4x5 driver for Linux then you probably don't need to do this).
See the web page for more information on how to do this and a program that can calculate the new MAC address for you. It is important that you set the new MAC address before TCP/IP is started. For Steve's kernels you must always set the ethernet MAC address.
The easiest way to this is to let startnet do it
in the DECnet startup file shipped with the dnprogs distribution. Alternatively,
if you have a Red Hat Linux system you can edit the file
/etc/sysconfig/network-scripts/ifcfg-eth0
to contain the line
MACADDR=AA:00:04:00:0A:04
(substitute your real MAC address for the one above unless your node
is 1.10!).
You probably haven't run startnet to configure the interface.
It is most likely that you have not configured your ethernet card to listen to the correct hardware address (see "What's all this about configuring my ethernet card?")
If you are running an "Eduardo kernel" and things spring back to life when you run "tcpdump" then this is almost certainly your problem.
Check that the decnet module is installed or compiled into the kernel. There should be a file /proc/net/decnet. If this does not exist then DECnet support is not installed. Check your kernel configuration.
Failing that check the /etc/decnet.conf file is set up correctly. If you installed the RPM files then a default one was installed that will certainly need editing for your site.
It is likely you have not added the node name to /etc/decnet.conf. The names of all nodes you need to communicate with must exist in this file if you want to refer to them by name.
You probably haven't turned on eth0, or whatever eth you're using. This is caused mainly by a DECnet-specific setup, since most normal setups assign an IP address to eth0 (using ifconfig) causing it to be enabled automatically.
To solve the problem do: "ifconfig eth0 up", or add that to your DECnet startup script.
Yes. This shows the address of the last router broadcast received.
Compared with Apache or Samba, DECnet is quite complicated to set up - kernel patching notwithstanding. The kernel code is integrated from Linux 2.3 so should appear in distributions when they start to adopt the 2.4 kernels.
Even so there is a still quite a lot of work to do to get DECnet working on your system. The main reason for this is that, unlike Samba, DECnet is a completely seperate networking system from TCP/IP. Whereas Samba and Apache layer their protocols on top of TCP/IP (and therefore require the other machines in the network to have a TCP/IP implementation) DECnet is completely seperate from that and only requires that it's peer machines have a DECnet implementation installed (usually this will be part of VMS).
The consequences of this are that you need to manage a new node/number namespace alongside your /etc/hosts or DNS database and that none of the usual TCP/IP configuation testing tools (apart from tcpdump) are of any use at all.
Also there is the added complication of having to change the MAC address of your ethernet card and I hope you will understand why this is not as simple as 'rpm -i samba*'.
I do try to make the installation as easy as possible and this will only get easier as the kernel code is shipped with distributions but if anyone has and better ideas to ease the installation and configuration process please join the mailing list and let us all know.
The kernel code is part of the standard 2.4 Linux kernel so I would imagine that a decnet.o module will be available on most distributions when they start shipping with 2.4 kernels. As for the user tools I cannot tell what Red Hat, SuSE etc will do.
However I can say the the next release of Debian (
http://www.debian.org
) will include the DECnet programs as I am packaging them myself. In fact
if you are running the current "unstable" release then the command
apt-get install dnet-progs
will get the latest version. You will need to be running a 2.4
kernel for this to work correctly.
This is because the default endnode hello timer for Phase V machines is set to 5 minutes, which means they get timed out of the Linux neighbour cache well before the next hello message appears. There are a number of ways round this:
1. If your machine has only one ethernet card you can make it the
default with the command echo "eth0" > /proc/sys/net/decnet/default_device.
2. Add a static route to the host using iproute2: ip -f dnet neigh add 1.31 dev eth1
3. Change the hello timer (probably the best solution but you to be need a VMS administrator to do it). Add the following line to the DECnet startup script. For VMS this is called SYS$STARTUP:NET$ROUTING_STARTUP.NCL, for Tru64 unix it is /usr/var/dna/scripts/start_routing.ncl
NCL SET ROUTING DEFAULT ESHELLO TIMER = 20
This line should go before the line that says "enable routing". You will need to stop and restart DECnet for this change to take effect.
Thanks to Colin Butcher and Rob Davies for number 3.
This is usually the same as the problem above.
First, make sure you have recompiled the dnprogs and installed them.
You may also need to add the following commands to your system startup sequence
(I'll fix the startup scripts shortly).
echo "1.10" > /proc/sys/net/decnet/node_address
echo "eth0" > /proc/sys/net/decnet/default_device
Change 1.10 above to be your node address and eth0 do be your default device for
DECnet communications. Of course, this must be done after the decnet module is loaded
(if you are using a DECnet as a module).
If you are using Debian GNU/Linux testing/unstable then simply
apt-get dnet-progs and answer the installation questions.
Because DECnet file specifications contain shell reserved characters (such as quotes and square brackets) it is usually necessary to enclose them in single quotes thus:
$ dncopy 'tramp"patrick password"::[.bin]forcex.exe' forcex.vax-exe
Because it's the most useful default. Unix files are stored as just a collection of bytes and where there is any record structure at all they are delimited by linefeed characters.
Sending files this way ensures that the files keep their data and structure as intact as possible and also means that C programs can lseek() the files on VMS. (other VMS file formats can only be accessed by record)
This format does *not* corrupt files as some people think. It may make them unreadable by certain applications that cannot handle STREAMLF files (which is quite common among non-C applications unfortunately) but the data should still be intact. If it is not then you have found a bug and I would like to know about it.
If it's a sequential file you are sending then adding the switches -rvar
-acr will make the file into a normal VMS text file. If it's a binary
file you are sending then you will need to know what block size to use.
When you know this send the file with the switches -mblock -b512
where 512 is the block size (not a bad guess usually).
Alternatively, and this is currently your only option for files copied using FAL, you could change the file attributes when the file has arrived on the VMS machine using the SET FILE/ATTR command (VMS 7) or the FILE command available on the VMS freeware CD.
I suppose it could, it just doesn't! FAL has a semi-automatic conversion system that could be incorporated into dncopy if I get the time (or the demand). It won't be perfect though, there are always plenty of exceptions that will need to be catered for manually. There is no magic algorithm that can generate FDL information from a random bucket of bytes.
You certainly can. If you use the special filename '-' (that's a hyphen) as the input file name then dncopy will read from standard input, using a hyphen as an output filename will send the file to standard output. Thus:
dncopy 'tramp::login.com' - | wc -l
will print the number of lines in your login.com file.
dncopy will copy all the data in a file (particularly if you use the -mblock switch) but it cannot copy file attributes such as key definitions. It will currently only copy sequential files to and from VMS. If you need to copy indexed or relative files then I recommend you back them up into a saveset and copy the saveset around.
dndir defaults to showing the file size in 512 byte blocks. This is what VMS does with its directory command. dndir will show the file size in bytes if you use the -b or -l switches.
No. You can use a system known as DECnet proxies. You will probably need
to speak to your OpenVMS administrator to set these up. The authorize command can associate remote users on remote machines with local users.
A common default (entered as *::* */DEFAULT) will associate all remote
users with a similarly named user on the local VMS machine. See your
OpenVMS administration guide for more details.
Be aware that many VMS system administrators do not like proxies and will refuse to set them up even if you ask very nicely.
It's arguably better because you have the full power of Unix regular expressions available to you rather than just the * and % of VMS wildcard characters. If you want the equivalent of a /DEFAULT proxy then just make sure it appears at the end of the file.
If you like. You will need to configure dnetd.conf to disable access control for the objects you want to enable the account for (probably fal). Though. in practice you probably wouldn't want to do this. It is more useful to set up a very restrictive set of proxies.
As with most Unix systems it's as secure as you want to make it, bugs permitting. It's probably nowhere near as secure as your VMS system because Unix just isn't.
You can restrict access to DECnet objects by careful editting of the
configuration files /etc/dnetd.conf and /etc/decnet.proxy.
See the man pages for the details
The most secure way to run the servers is to use dnetd, which is then the only daemon that needs to run as root. You can then force all other daemons to run as non-privileged users. dnetd is a very small program and so easier to secure and less likely to be buggy than something huge and complicated such as fal.
The implementation of outgoing proxies is not secure (this will improve) so if you are concerned about security you should NOT allow DECnet proxies from Linux machines on your VMS systems.
Also, don't forget that DECnet always sends passwords in clear text.
Yes, if you run fal. FAL is part of the standard dnprogs distribution and
is started by default if you use the installation scripts provided. So all
your VMS users need to get access to Linux files is a username on the Linux
box. It is possible to set up DECnet proxies to help with this. type
man decnet.proxy for details.
Almost certainly this means that no daemons are running to accept connections on the Linux box. Usually this means you need to start dnetd. Using the "ps" command first make sure that dnetd is not running. If not then start it manually and check that connections now work. If so then you may need to go over the startup script to make sure that it has the correct path for dnetd and that the script itself is being run at system startup.
If you still get the same message, check that dnetd is still running. If it is not then try running it in the forground "dnetd -dvvle" and see if any messages appear that indicate a problem. You might also like to try "strace dnetd -dvvle" and send the resulting output to the mailing list for me to look at.
Please note also that there is a terrible memory leak in dnetd up to and including dnprogs 2.05 which may cause it to crash after a while on a busy system. If this sounds like your symptoms them please upgrade to dnprogs 2.06 or later.
You'll need to set the MAC address of your ethernet card. See the "Configuration" part of this FAQ for more details.
It usually means that the command procedure does not exist on the OpenVMS machine, although it could also mean that the username/password was wrong or the DECnet proxies are not set up correctly. Another reason is that the TASK object was disabled by your system administrator because it is a potential security hole.
I'm sorry the error message isn't more helpful but DECnet simply refuses connections to unknown objects so there's not a great deal I can do about it. Sorry
Possibly you don't have the latest kernel patch on your system. dnprogs 2.0 and higher requires you to have Eduardo's kernel patch 0.0.11 or higher or Kernel 2.4.x. If you cannot upgrade your kernel patch (though I recommend you do so) then you should use dnprogs 1.05.
If you are sure you have an up-to-date kernel then check that dnetd is really running and that you have a valid file in /etc/dnetd.conf. If dnetd is not running and you started it then startnet may not have been run. See if you can see VMS systems from the Linux machine first.
The first thing to remember is that the command procedure on the OpenVMS machine must always send some output to SYS$NET, even if you are just launching an X-windows application (see DECTERM.COM), the DECnet protocol demands it.
Also remember that accessing command procedures as objects is actually quite a low-level function so things can break very easily. Make sure that the switches you give to dntask match the characteristics of the remote command procedure. If your object is behaving strangely it may be useful to look in the NETSERVER.LOG files in the SYS$LOGIN directory of the remote user. If you want to debug a task then WRITEs to SYS$OUTPUT will appear in NETSERVER.LOG too so you can trace what is happening.
This is normally caused by trying to copy a file with very long records, usually larger than 4156 bytes. It is caused by VMS not allocating a large enough network buffer to do the transfer.
To fix this enter the following DCL command before attempting the transfer:
$ SET RMS_DEFAULT /NETWORK_BLOCK_COUNT=127
If you want to make this a global, system-wide default then set the SYSGEN parameter RMS_DFNBC to 127. It is a dynamic paramter so it will take effect immediately. Don't forget to add it to MODPARAMS.DAT and/or write it to CURRENT so it also takes effect at the next system reboot
I want to see them!
By the 1.02 release I think that all the outstanding protocol errors have been fixed. If you are running this release (or later) then please enable fal logging by running the binary with lots of v switches (eg fal -dlevvvvvvvvvvv will run fal in the foreground and send logging messages to stderr) and send the result to the mailing list. It is also helpful to state your VMS version.
In certain cases it may be useful to see 'tcpdump' output. Use the command
tcpdump -x -s1500 decnet and send me the output.
The file /etc/dnetd.conf defines which services are available
to external users. To remove one simply delete it's line or comment it
out with a hash (#) character. You should also make sure that the daemon
is not already running as root using the 'ps' command.
It could be that you are using an early version of dnprogs which had a bug in this area - make sure you are using dnprogs 1.93 or later.
If you are running the latest dnprogs then it's likely that the daemon has been started standalone. If the only daemon running is dnetd then it will start all daemons with the parameters specified in /etc/dnetd.conf. If you then log in as root and start (say) fal from the command-line then it will be *that* version of fal that will service incoming connections. dnetd only handles incoming connections that do not already have daemons listening.
Since Linux does not use UIC numbers and the Unix UID/GID structure does not match the way VMS uses UICs the display of UICs from VMS is a bit meaningless. All that FAL does is to show you the group id and user id in octal: [GID,UID]. Since Unix normally uses decimal for such numbers they will look very odd shown in octal.
It probably is. Unix has no concept of a Created date for a file. Only the wonderfully named Changed and Modified dates. FAL uses the lowest of these two for the created date and the modified date for the revision date.
If you want to use phone then you must start phoned, even if you are running dnetd. phoned provides services to phone client users on the local machine as well as to phone users on remote systems who want to phone local users. The reasons for this are many and complicated so just believe me!
This is a bug in either startnet or the Eduardo kernel patch; I don't honestly know which. It seems very hard to track down and as the problem does not occur with the Steve's new patches I have decided to work around it.
You need to download the kernel patch 0.0.14 from the web site and build it as a kernel module. Then insert the module with parameters node= and device= to configure it. eg:
modprobe decnet node=1,10 device=eth0
You do not need to run startnet if you do this. If you use the supplied startup script and insert the module before the script runs then it will be bypassed automatically.
This is usually caused by upgrading to Linux 2.4 (the "Steve" kernels) without recompiling the dnprogs package. Because of differences between the two implementations (mainly caused by me writing non-standard behaviour into the kernel to make the userland bits easier and then forcing it onto Eduardo) you must compile the dnprogs package for the kernel type you are using. So if you move from an Eduardo kernel (from sourceforge or linux.dreamtime.org) to a Steve kernel (from sucs.swan.ac.uk or included in kernel 2.4) you must recompile.
Note that this is a one-off procedure. You do NOT need to recompile for each kernel upgrade after that.
The binaries available from sourceforge are compiled for Eduardo kernels and are not suitable for Steve kernels - you must compile them yourself. This will change soon after the release of the 2.4 kernel: watch the mailing list for an announcement.
Unfortunately not at the moment. I am disgustingly monoglot for which I apologise. Blame my own laziness or the English education system. If anyone is prepared to do the translations of messages into other languages then I will be happy to internationalise the code to make it possible. Please contact me via the mailing list.