[HECnet] DECnet for Linux Bug Fixes

Thu Jul 9 10:31:20 PDT 2020

I took a look at providing pre-built system images and decided not for a couple of reasons:

	- Some (all?) release images contain licensed code and I don’t feel comfortable re-hosting such material
	- Pre-built image will soon become outdated. There are 3 or 4 releases a year and I don’t want to spend a
	  lot of time keeping images up to date

To simplify installation, I’ve written a shell script (BuildAndInstall.sh) to perform most of the work. Copy it to an empty
directory on the target Pi, make it executable and run it. It will ask a few questions (DECnet node name, address etc)
before cloning the Linux and DECnet repositories and building everything tailored for the Raspberry Pi it is running on.
More details are available at github.

  John.

> On Jun 30, 2020, at 12:13 PM, John Forecast <john at forecast.name> wrote:
> 
> 
>> On Jun 30, 2020, at 10:29 AM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
>> 
>> Hello!
>> Something else, all of my PI devices, from one from Seven years ago
>> last December to one that arrived perhaps two years previously are all
>> 32 bit devices, the build-it instructions presuppose that a lot of us
>> own Pi4 devices who're 64 bit capable. That card image the both of us
>> are interested in would need to work on both style systems.
>> -----
>> Gregg C Levine gregg.drwho8 at gmail.com
>> "This signature fought the Time Wars, time and again."
> 
> Let me just say that almost all of my testing has been in 32-bit Raspbian on either a Pi Zero W or an original Pi 1B. If you ignore section 2.3 of Raspbian.README, the document describes how to install DECnet on a 32-bit system.
> 
> I’m not going to commit to building an image until I understand all of the ramifications. Since RPT is moving 2 versions of piOS (32 and 64-bit kernels and associated userland code), I would only consider building piOS images. Fortunately, the 64-bit PiOS has not been released yet so we’re really only talking about a single image.
> 
> Let me see how much work is involved.
> 
>  John.
> 
>> 
>> On Tue, Jun 30, 2020 at 10:25 AM Gregg Levine <gregg.drwho8 at gmail.com> wrote:
>>> 
>>> Hello!
>>> How about he's right? I do know I could sit down in front of an SSH
>>> terminal screen to an appropriate device and use the git tool to
>>> download the code and follow the instructions that should be inside
>>> the README file. However there must be some of us out on the list who
>>> can do that, but would rather use a previously constructed image for
>>> the purpose.
>>> -----
>>> Gregg C Levine gregg.drwho8 at gmail.com
>>> "This signature fought the Time Wars, time and again."
>>> 
>>> On Tue, Jun 30, 2020 at 10:12 AM Supratim Sanyal <supratim at riseup.net> wrote:
>>>> 
>>>> On 6/29/2020 20:45, John Forecast wrote:
>>>> 
>>>> Recently I have found, and fixed, a number of bugs in the DECnet for Linux kernel module. Some of
>>>> these bugs may be relevant for members of this mailing list who are using DECnet for Linux,
>>>> especially on a Raspberry Pi.
>>>> 
>>>> John - how about making our pandemic and politician-stressed lives a bit easier and uploading a microSD image somewhere relieving us from having to go through the hoops?
>>>> 
>>>> https://github.com/JohnForecast/RaspbianDECnet/blob/master/README.Raspbian is fantastic, BTW.
>>>> 
>>>> :)
>>>> 
>>>> Regards
>>>> Supratim
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Major bugs fixed:
>>>> 
>>>> - Ethernet Listen Timer was not implemented
>>>> 
>>>> In addition, the check for an address change for the designated router (DR) was missing
>>>> although there was a check if the DR’s priority had changed.
>>>> 
>>>> Note: this code changes the format of /proc/net/decnet_dev to include the listen timer value.
>>>>         nml/nml2 needs to be rebuilt to understand the changed format.
>>>> 
>>>> - System panic when using the loopback device (lo)
>>>> 
>>>> The DECnet code was missing a destructor routine which is used to avoid data copying.
>>>> 
>>>> - The neighbour (adjacent node) code could be broken by kernel changes
>>>> 
>>>> The code made use of a now deprecated feature (zero length array at the end of a structure)
>>>> in order to access data in a surrounding structure. This happened to work “by chance”
>>>> until kernel 5.4.42 on 32-bit processors.
>>>> 
>>>> - Interrupt message flow control was broken
>>>> 
>>>> The flow control was a mixture of using the SEND/DONTSEND status of the data
>>>> subchannel and a message count. This seems to work between Linux systems but is broken
>>>> when communicating with other systems - during the life of a logical link, the remote system
>>>> could only send a single interrupt message while the Linux system could pretty much send
>>>> as many interrupts as it wanted possibly overrunning the remote systems buffers.
>>>> 
>>>> - Optional data on received connect confirm message was corrupted
>>>> 
>>>> The code was getting the optional data from the wrong offset in the message.
>>>> 
>>>> - Next hop cache problem
>>>> 
>>>> 30 seconds after a logical link was taken down, the next hop cache entry was deleted. As
>>>> part of this deletion, the link was taken “down” which caused a neighbour entry to be
>>>> created for the same node address but accessed via the loopback device. Sometimes this
>>>> would cause the designated router to become accessible via the loopback device and
>>>> subsequent connections would fail.
>>>> 
>>>> - Intra-ethernet bit ignored
>>>> 
>>>> The intra-ethernet bit in the routing flags is ignored on inbound traffic. If there was a neighbour
>>>> entry for the remote node at connection time, everything would work correctly. If there wad no
>>>> entry, all outbound  traffic would be sent through the designated router for the duration of
>>>> the logical link.
>>>> 
>>>> - Promiscuous mode alters DECnet behaviour
>>>> 
>>>> If the ethernet NIC used for DECnet had promiscuous mode enabled (e.g. using tcpdump
>>>> for traffic tracing), the DECnet code would start seeing endnode hello’s, populating
>>>> neighbour structures and causing the problems described above for the intra-ethernet bit
>>>> to go away.
>>>> 
>>>> New programs:
>>>> 
>>>> DECnet Test Send and DECnet Test Receiver (DTS/DTR)
>>>> 
>>>> Test programs created via reverse engineering the protocol exchanges. Used to find a
>>>> number of the bugs described above.
>>>> 
>>>> NML2
>>>> 
>>>> New implementation of the Network Management Listener. Supports SUMMARY, STATUS
>>>> and CHARACTERISTICS for NODES, CIRCUITS and AREAS. It does not support LINKS
>>>> and OBJECTS which were in the old version but are system specific operations which
>>>> were only visible from DECnet-VMS systems.
>>>> 
>>>> The old version is still the default during installation. The new version can be installed by:
>>>> 
>>>> cd dnprogs/nml2
>>>> make
>>>> sudo make install
>>>> 
>>>> which will overwrite the installed executable and man page.
>>>> 
>>>> OS Support:
>>>> 
>>>> As of 06/29/2020 the code has been tested with:
>>>> 
>>>> Raspbian 2020-05-27 release with kernels 4.19.126 and 5.4.44 (32-bit only)
>>>> 
>>>> Pi OS 2020-05-27 32-bit release with kernel 4.19.126 and 5.4.44
>>>> 
>>>> pI OS 2020-05-27 (fully updated on 06/26/2020) with kernel 5.4.49
>>>> 
>>>> 
>>>> The source code and installation instructions are available at:
>>>> 
>>>> <https://github.com/JohnForecast/RaspbianDECnet>
>>>> 
>>>> John.
>>>> 
>>>> --
>>>> Supratim Sanyal, W1XMT
>>>> 39.19151 N, 77.23432 W
>>>> QCOCAL::SANYAL via HECnet
> 