<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi David,<div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2020, at 9:44 PM, David Moylan <<a href="mailto:djm@wiz.net.au" class="">djm@wiz.net.au</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><meta name="Generator" content="Microsoft Word 14 (filtered medium)" class=""><style class=""><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MailQuote, li.MailQuote, div.MailQuote
        {mso-style-name:"Mail Quote";
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        border:none;
        padding:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.apple-tab-span
        {mso-style-name:apple-tab-span;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space" class=""><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">Hi John,<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">This is amazing news. I have been unable to use DECnet under Linux for a very long time as the implementation was broken.<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">The last time I saw DECnet for Linux working was back in the Ubuntu 14 timeframe. Nothing modern worked at all with the end result usually being the entire VM locking as soon as you went to initiate any form of DECnet connection (this required a power cycle or reset to recover).<o:p class=""></o:p></span></p><p class="MsoNormal"><br class=""></p></div></div></div></blockquote><div><br class=""></div>Mostly it seems to have been a case of benign neglect - a new feature/function is added to the kernel and someone modifies the DECnet code to make sure it still compiles but there’s no-one around to do any testing.</div><div><br class=""><blockquote type="cite" class=""><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space" class=""><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">I did some research and it looked like no-one was maintaining the code. I saw a few attempts from a few people to resurge this, but I could never get their code trees to compile.<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">I noticed in the readme that you’ve previously used this with Debian Buster 10 which puts this in a similar space to Ubuntu 18.04 Bionic, but your comments said “Due to kernel changes, the above no longer work.”<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">So should I be able to use your kernel module code under Ubuntu 18.04 (running kernel 4.15.0 or similar) or has something recently broken?<o:p class=""></o:p></span></p><p class="MsoNormal"><br class=""></p></div></div></blockquote><div><br class=""></div>The code as it stands today will probably not even compile with a 4.15.0 tree - all of my building/testing has been done on 4.19 and 5.4. Since writing the above note about “kernel changes” I’ve had to figure out the Linux versioning macros. It should be pretty easy to back out that particular change and add a version check - it’s only two calls to a kernel routine which added an extra argument which DECnet doesn’t use. The harder problem is finding out which version made the change. With these changes, there’s a good chance that it will work on 4.15 although no guarantees! Let me know if you want me to make those changes.</div><div><br class=""></div><div>  John.</div><div><br class=""><blockquote type="cite" class=""><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space" class=""><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">Cheers, Wiz!!<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""><o:p class=""> </o:p></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt" class=""><div class=""><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm" class=""><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> <a href="mailto:owner-hecnet@Update.UU.SE" class="">owner-hecnet@Update.UU.SE</a> [<a href="mailto:owner-hecnet@Update.UU.SE" class="">mailto:owner-hecnet@Update.UU.SE</a>] <b class="">On Behalf Of </b>John Forecast<br class=""><b class="">Sent:</b> Tuesday, 30 June 2020 10:45 AM<br class=""><b class="">To:</b> <a href="mailto:hecnet@update.uu.se" class="">hecnet@update.uu.se</a><br class=""><b class="">Subject:</b> [HECnet] DECnet for Linux Bug Fixes<o:p class=""></o:p></span></p></div></div><p class="MsoNormal"><o:p class=""> </o:p></p><div class=""><p class="MsoNormal">Recently I have found, and fixed, a number of bugs in the DECnet for Linux kernel module. Some of<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">these bugs may be relevant for members of this mailing list who are using DECnet for Linux,<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">especially on a Raspberry Pi.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">Major bugs fixed:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Ethernet Listen Timer was not implemented<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>In addition, the check for an address change for the designated router (DR) was missing<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>although there was a check if the DR’s priority had changed.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>Note: this code changes the format of /proc/net/decnet_dev to include the listen timer value.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>          nml/nml2 needs to be rebuilt to understand the changed format.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- System panic when using the loopback device (lo)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The DECnet code was missing a destructor routine which is used to avoid data copying.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- The neighbour (adjacent node) code could be broken by kernel changes<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The code made use of a now deprecated feature (zero length array at the end of a structure)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>in order to access data in a surrounding structure. This happened to work “by chance”<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>until kernel 5.4.42 on 32-bit processors.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Interrupt message flow control was broken<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The flow control was a mixture of using the SEND/DONTSEND status of the data<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>subchannel and a message count. This seems to work between Linux systems but is broken<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>when communicating with other systems - during the life of a logical link, the remote system<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>could only send a single interrupt message while the Linux system could pretty much send<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>as many interrupts as it wanted possibly overrunning the remote systems buffers.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Optional data on received connect confirm message was corrupted<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The code was getting the optional data from the wrong offset in the message.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Next hop cache problem<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>30 seconds after a logical link was taken down, the next hop cache entry was deleted. As<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>part of this deletion, the link was taken “down” which caused a neighbour entry to be<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>created for the same node address but accessed via the loopback device. Sometimes this<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>would cause the designated router to become accessible via the loopback device and<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>subsequent connections would fail.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Intra-ethernet bit ignored<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The intra-ethernet bit in the routing flags is ignored on inbound traffic. If there was a neighbour<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>entry for the remote node at connection time, everything would work correctly. If there wad no<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>entry, all outbound  traffic would be sent through the designated router for the duration of<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>the logical link.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">- Promiscuous mode alters DECnet behaviour<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>If the ethernet NIC used for DECnet had promiscuous mode enabled (e.g. using tcpdump<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>for traffic tracing), the DECnet code would start seeing endnode hello’s, populating<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>neighbour structures and causing the problems described above for the intra-ethernet bit<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>to go away.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">New programs:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">DECnet Test Send and DECnet Test Receiver (DTS/DTR)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>Test programs created via reverse engineering the protocol exchanges. Used to find a<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>number of the bugs described above.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">NML2<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>New implementation of the Network Management Listener. Supports SUMMARY, STATUS<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>and CHARACTERISTICS for NODES, CIRCUITS and AREAS. It does not support LINKS<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>and OBJECTS which were in the old version but are system specific operations which<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>were only visible from DECnet-VMS systems.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>The old version is still the default during installation. The new version can be installed by:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>cd dnprogs/nml2<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>make<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>sudo make install<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>which will overwrite the installed executable and man page.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">OS Support:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span>As of 06/29/2020 the code has been tested with:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>Raspbian 2020-05-27 release with kernels 4.19.126 and 5.4.44 (32-bit only)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>Pi OS 2020-05-27 32-bit release with kernel 4.19.126 and 5.4.44<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">                      </span>pI OS 2020-05-27 (fully updated on 06/26/2020) with kernel 5.4.49<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">The source code and installation instructions are available at:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"><span class="apple-tab-span">          </span><<a href="https://github.com/JohnForecast/RaspbianDECnet" class="">https://github.com/JohnForecast/RaspbianDECnet</a>><o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">  John.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div></div></div></div></blockquote></div><br class=""></div></div></body></html>