30 Jun
2020
30 Jun
'20
2:45 a.m.
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.
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
<https://github.com/JohnForecast/RaspbianDECnet>>
John.
30 Jun
30 Jun
3:44 a.m.
Hi John,
This is amazing news. I have been unable to use DECnet under Linux for a very long time as
the implementation was broken.
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).
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.
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.?
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?
Cheers, Wiz!!
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of John
Forecast
Sent: Tuesday, 30 June 2020 10:45 AM
To: hecnet at update.uu.se
Subject: [HECnet] DECnet for Linux Bug Fixes
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.
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.
5:52 p.m.
Hi David,
On Jun 29, 2020, at 9:44 PM, David Moylan <djm at
wiz.net.au> wrote:
Hi John,
This is amazing news. I have been unable to use DECnet under Linux for a very long time
as the implementation was broken.
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).
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.
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.
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.?
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?
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.
John.
Cheers, Wiz!!
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
John Forecast
Sent: Tuesday, 30 June 2020 10:45 AM
To: hecnet at update.uu.se
Subject: [HECnet] DECnet for Linux Bug Fixes
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.
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
<https://github.com/JohnForecast/RaspbianDECnet>>
John.
4:12 p.m.
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
4:25 p.m.
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
4:29 p.m.
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."
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
6:13 p.m.
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
9 Jul
9 Jul
7:31 p.m.
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
9:16 p.m.
On Jul 9, 2020, at 1:43 PM, Dennis Boone <drb at
msu.edu> wrote:
This is the first I?ve heard of DKMS and it looks interesting. As far as I can see it?s
really targeted at self-contained
modules which can be built using just the kernel header files and, maybe, some library
files. Unfortunately, DECnet
is part of the standard kernel tree and turning on DECNET_CONFIG enables some code in the
core networking code
and changes the layout of some data structures which are used throughout the kernel. Like
most of the networking code it is tightly integrated into the kernel. So, in order to
update the DECnet I code I have to download the kernel source, make some changes and
rebuild the kernel+modules. Now there?s nothing for DKMS to do.
John.
To simplify installation, I?ve written a shell
script
(BuildAndInstall.sh) to perform most of the work.
To my mind, DKMS would be the ideal way to "package" this stuff. Nearly
anything homebrew is going to have un-noticed distro- or hardware
platform-specific dependencies.
De 
30 Jun
30 Jun
5:21 p.m.
Hi.
On 2020-06-30 02: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.
Cool.
New programs:
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.
Um. No. OBJECTS are also there in RSX. And I wonder if you mean LINES
when you wrote LINKS. And LINES are also in RSX. Not sure there are some
other systems that also have those types. But they are definitely not
VMS only... And OBJECTS are actually rather relevant everywhere, it's
just not that all systems make them visible. I would say it's actually
nice and useful if they can be shown. LINES are also relevant, but it
does depend a little on the implementation.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
6:54 p.m.
On Jun 30, 2020, at 11:21 AM, Johnny Billquist <bqt
at softjar.se> wrote:
...
OBJECTS is a system dependent entity. And if LINKS means logical links (DECnet virtual
circuits) then the same is true there. RSTS has both. But they are implemented by
system-dependent commands, so they don't work across operating systems. Unfortunately
NCP didn't think of having OS-dependent entities, the way EVTLOG does -- that would
have allowed other OSs to interpret things by adding the OS-specific knowledge.
paul
New programs:
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.
Um. No. OBJECTS are also there in RSX. And I wonder if you mean LINES when you wrote
LINKS. And LINES are also in RSX. Not sure there are some other systems that also have
those types. But they are definitely not VMS only... And OBJECTS are actually rather
relevant everywhere, it's just not that all systems make them visible. I would say
it's actually nice and useful if they can be shown. LINES are also relevant, but it
does depend a little on the implementation.
7:09 p.m.
On Jun 30, 2020, at 11:21 AM, Johnny Billquist <bqt
at softjar.se> wrote:
Hi.
On 2020-06-30 02:45, John Forecast wrote:
No, I?m talking about how entities are handled in the NICE protocol. SET/DEFINE/SHOW/LIST
commands on NODES, LINES, LOGGING, CIRCUITS, MODULES and AREAS use a common protocol
format so that VMS, for instance, can issue a ?SHOW KNOWN NODES? to RSX, Ultrix etc. LINKS
and OBJECTS are considered system dependent entities and and for operations on those
entities NCP will send a request as:
<System-Specific-Function (code 22)>
<Originating system type (VMS == 4)>
<Binary data>
Here?s Ultrix issuing commands to a VMS system:
# ncp tell router sho exec
Executor Volatile Summary as of Sun Jul 1 08:47:44 EDT 1990
Executor node = 63.1 (ROUTER)
State = On
Identification = DECnet for OpenVMS VAX V7.3
# ncp tell router sho known objects
Known Object Volatile Summary as of Sun Jul 1 08:48:00 EDT 1990
ncp - listener response: System-specific Management function not supported
#
For LINES, I?m not sure there is much useful information we can display. Here?s Ultrix
again:
#ncp sho kno lin char
Known Line Volatile Characteristics as of Sun Jul 1 09:00:49 EDT 1990
Line = QNA-0
Controller = Normal
Protocol = Ethernet
Hardware address = aa-00-04-00-df-fc
John.
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.
Cool.
New programs:
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.
Um. No. OBJECTS are also there in RSX. And I wonder if you mean LINES when you wrote
LINKS. And LINES are also in RSX. Not sure there are some other systems that also have
those types. But they are definitely not VMS only... And OBJECTS are actually rather
relevant everywhere, it's just not that all systems make them visible. I would say
it's actually nice and useful if they can be shown. LINES are also relevant, but it
does depend a little on the implementation.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8:59 p.m.
On 2020-06-30 19:09, John Forecast wrote:
I did understand that. :-)
On Jun 30, 2020, at 11:21 AM, Johnny Billquist
<bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Hi.
On 2020-06-30 02:45, John Forecast wrote:
No, I?m talking about how entities are handled in the NICE protocol. 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.
Cool.
New programs:
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.
Um. No. OBJECTS are also there in RSX. And I wonder if you mean LINES
when you wrote LINKS. And LINES are also in RSX. Not sure there are
some other systems that also have those types. But they are definitely
not VMS only... And OBJECTS are actually rather relevant everywhere,
it's just not that all systems make them visible. I would say it's
actually nice and useful if they can be shown. LINES are also
relevant, but it does depend a little on the implementation.
SET/DEFINE/SHOW/LIST commands on NODES, LINES,
LOGGING, CIRCUITS,
MODULES and AREAS use a common protocol format so that VMS, for
instance, can issue a ?SHOW KNOWN NODES? to RSX, Ultrix etc. LINKS and
OBJECTS are considered system dependent entities and and for operations
on those entities NCP will send a request as:
<System-Specific-Function (code 22)>
<Originating system type (VMS == 4)>
<Binary data>
Here?s Ultrix issuing commands to a VMS system:
# ncp tell router sho exec
Executor Volatile Summary as of Sun Jul? 1 08:47:44 EDT 1990
Executor node =? 63.1 (ROUTER)
State? ? ? ? ? ? ? ? ? ? ? ? ? ? ? = On
Identification ? ? ? ? ? ? ? ? ? ? = DECnet for OpenVMS VAX V7.3
# ncp tell router sho known objects
Known Object Volatile Summary as of Sun Jul? 1 08:48:00 EDT 1990
ncp - listener response: System-specific Management function not supported
#
I could have sworn that RSX understood VMS regarding objects, but now
that I tried, it did not.
So I might have been totally confused. RSX also have the command to
examine objects through NCP, but it would appear to be incompatible with
the VMS NICE listener then.
In RSX:
.ncp tell jocke sho kno obj
Known objects summary as of 30-JUN-20 20:58:44
Object Name Copies User Verification
0 Single Default Off
15 TCL... Single Default On
16 LSN$$$ 5 Default Off
17 FAL$$$ 8 Login On
18 HLD... Single Default Off
19 NIC$$$ 5 Default Inspect
23 RMHACP Single Default Off
25 MIR$$$ 5 Default Off
26 EVR$$$ 5 Default Off
27 MAI$$$ 5 Default Off
29 PHO$$$ 5 Default Off
30 DDM$$$ 5 Login On
42 RTH Single Default Off
63 DTR... Single Default Off
.
For LINES, I?m not sure there is much useful
information we can display.
Here?s Ultrix again:
#ncp sho kno lin char
Known Line Volatile Characteristics as of Sun Jul? 1 09:00:49 EDT 1990
Line? =? QNA-0
Controller ? ? ? ? ? ? ? ? ? ? ? ? = Normal
Protocol ? ? ? ? ? ? ? ? ? ? ? ? ? = Ethernet
Hardware address ? ? ? ? ? ? ? ? ? = aa-00-04-00-df-fc
As far as lines goes, yes, there is not too much information available
on them.
From RSX to a VMS node, compared to another RSX node:
.ncp tell frost sho line qna-0 cha
Line characteristics as of 30-JUN-20 20:54:43
Line = QNA-0
Receive buffers = 10, Controller = Normal
Protocol = ETHERNET
Service timer = 4000
Hardware address = AA-00-04-00-FF-63
Buffer size = 1498
.ncp tell jocke sho lin una-0 cha
Line characteristics as of 30-JUN-20 20:55:00
Line = UNA-0
Controller = Normal
Counter timer = Off
Protocol = ETHERNET
Hardware address = AA-00-04-00-15-04
Controller CSR = 174510, Vector = 120
Priority = 5
.
Do people care about this information? Maybe not.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
9:44 p.m.
On Jun 30, 2020, at 2:59 PM, Johnny Billquist <bqt
at softjar.se> wrote:
It depends. On RSTS there are some line characteristics that don't belong there (left
over from the old days when circuit didn't exist yet) but also one or two that do. In
particular, DDCMP lines have a "receive buffers" parameter that lets you tune
how many buffers are given to that device. That's one of the few parameters that
matters. Oh yes, "verification" which should be a circuit parameter is a line
parameter instead, I'm not sure why.
paul
...
As far as lines goes, yes, there is not too much information available on them.
From RSX to a VMS node, compared to another RSX node:
.ncp tell frost sho line qna-0 cha
Line characteristics as of 30-JUN-20 20:54:43
Line = QNA-0
Receive buffers = 10, Controller = Normal
Protocol = ETHERNET
Service timer = 4000
Hardware address = AA-00-04-00-FF-63
Buffer size = 1498
.ncp tell jocke sho lin una-0 cha
Line characteristics as of 30-JUN-20 20:55:00
Line = UNA-0
Controller = Normal
Counter timer = Off
Protocol = ETHERNET
Hardware address = AA-00-04-00-15-04
Controller CSR = 174510, Vector = 120
Priority = 5
.
Do people care about this information? Maybe not. 
6:58 p.m.
On 6/29/2020 7:45 PM, 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.
The source code and installation instructions are available at:
<https://github.com/JohnForecast/RaspbianDECnet>
? John.
Are any of these changes appropriate for sending to the DECnet Linux maintenance
site?
Project Home Page:https://sourceforge.net/projects/linux-decnet/
Linux-decnet-user mailing list
Linux-decnet-user at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user
--
John H. Reinhardt
6 Nov
6 Nov
2:55 a.m.
On Jun 29, 2020, at 8:45 PM, John Forecast <john at
forecast.name> 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.
I've spent a bit of time with John's latest code to see how it works on other
platforms.
The answer is "quite nicely". I dropped his changed files into a Fedora Core 32
(the latest release, as of a couple of weeks ago anyway) sources, and built their 5.8.17
kernel with DECnet enabled, for 64-bit x86.
It works, no major problems seen. This is the endnode; I haven't tried a router yet.
Very nice.
paul
9:55 a.m.
On 2020-11-06 02:55, Paul Koning wrote:
I had serious problems using it to talk to RSX in the past (many years
ago). Have you tried accessing in both directions between an RSX node
and that? It might be it has been improved a lot since I tried, but I am
a little concerned that it's mostly just been tested against VMS.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jun 29, 2020, at 8:45 PM, John Forecast
<john at forecast.name> 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.
I've spent a bit of time with John's latest code to see how it works on other
platforms.
The answer is "quite nicely". I dropped his changed files into a Fedora Core
32 (the latest release, as of a couple of weeks ago anyway) sources, and built their
5.8.17 kernel with DECnet enabled, for 64-bit x86.
It works, no major problems seen. This is the endnode; I haven't tried a router
yet.
Very nice.
3:12 p.m.
On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2020-11-06 02:55, Paul Koning wrote:
I had serious problems using it to talk to RSX in the past (many years ago). Have you
tried accessing in both directions between an RSX node and that? It might be it has been
improved a lot since I tried, but I am a little concerned that it's mostly just been
tested against VMS.
I did DAP access to MIM ("dndir"), that worked. Didn't try a whole lot else
yet. But I ran a bunch of operations against RSTS.
paul
On Jun
29, 2020, at 8:45 PM, John Forecast <john at forecast.name> 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.
I've spent a bit of time with John's latest
code to see how it works on other platforms.
The answer is "quite nicely". I dropped his changed files into a Fedora Core
32 (the latest release, as of a couple of weeks ago anyway) sources, and built their
5.8.17 kernel with DECnet enabled, for 64-bit x86.
It works, no major problems seen. This is the endnode; I haven't tried a router
yet.
Very nice.
4:20 p.m.
On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2020-11-06 02:55, Paul Koning wrote:
I had serious problems using it to talk to RSX in the past (many years ago). Have you
tried accessing in both directions between an RSX node and that? It might be it has been
improved a lot since I tried, but I am a little concerned that it's mostly just been
tested against VMS.
You're right, the initial testing was against VMS, but it wasn't all that long
after that I spent a bunch of time getting it to work better with others. For example,
that's why the "old remote terminal protocol" is implemented in Linux.
Just tried some tests.
RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works. DAP doesn't, it
gets "Tasks out of synchronization".
Linux to RSX: mirror works, cterm works, dap works.
RSTS to Linux: NCP works, LOOP NOD works, SET HOST works. DAP fails with a message
indicating an Interrupt message is mishandled. (DAP is one of the few protocols that uses
interrupts.)
Linux to RSTS: mirror works, cterm is not supported by RSTS, "sethost"
doesn't work because the connect fails in a way that doesn't reach the check for
"no such object" status. DAP partly works, but the directory listing only shows
the last file rather than all of them.
Haven't tried VMS yet, the VMS system I have access to seems to be down right now.
paul
On Jun
29, 2020, at 8:45 PM, John Forecast <john at forecast.name> 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.
I've spent a bit of time with John's latest
code to see how it works on other platforms.
The answer is "quite nicely". I dropped his changed files into a Fedora Core
32 (the latest release, as of a couple of weeks ago anyway) sources, and built their
5.8.17 kernel with DECnet enabled, for 64-bit x86.
It works, no major problems seen. This is the endnode; I haven't tried a router
yet.
Very nice.
8:47 p.m.
On Nov 6, 2020, at 10:20 AM, Paul Koning
<paulkoning at comcast.net> wrote:
> On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt at softjar.se> wrote:
>
> On 2020-11-06 02:55, Paul Koning wrote:
>>> On Jun 29, 2020, at 8:45 PM, John Forecast <john at forecast.name>
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.
>> I've spent a bit of time with John's latest code to see how it works on
other platforms.
>> The answer is "quite nicely". I dropped his changed files into a
Fedora Core 32 (the latest release, as of a couple of weeks ago anyway) sources, and built
their 5.8.17 kernel with DECnet enabled, for 64-bit x86.
>> It works, no major problems seen. This is the endnode; I haven't tried a
router yet.
>> Very nice.
>
I?ve never even built the router version of the code. It is marked ?experimental? in Linux
config.
I had serious
problems using it to talk to RSX in the past (many years ago). Have you tried accessing in
both directions between an RSX node and that? It might be it has been improved a lot since
I tried, but I am a little concerned that it's mostly just been tested against VMS.
You're right, the initial testing was against VMS, but it wasn't all that long
after that I spent a bunch of time getting it to work better with others. For example,
that's why the "old remote terminal protocol" is implemented in Linux.
Just tried some tests.
RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works. DAP doesn't, it
gets "Tasks out of synchronization".
Linux to RSX: mirror works, cterm works, dap works.
RSTS to Linux: NCP works, LOOP NOD works, SET HOST works. DAP fails with a message
indicating an Interrupt message is mishandled. (DAP is one of the few protocols that uses
interrupts.)
Linux to RSTS: mirror works, cterm is not supported by RSTS, "sethost"
doesn't work because the connect fails in a way that doesn't reach the check for
"no such object" status. DAP partly works, but the directory listing only shows
the last file rather than all of them.
Haven't tried VMS yet, the VMS system I have access to seems to be down right now.
paul
John.
7 Nov
7 Nov
12:45 a.m.
If you don't mind experimental code, you can anonymosly test it against
my modified Tops-20 DAP/FAL server.
You can contact me offline to set something up.
On 11/6/20 2:47 PM, John Forecast wrote:
It also tries to pretend that it is VMS, both nml and fal. I?ve written new
versions of both; nml2 no longer responds to VMS system specific commands and fal2 mostly
uses user-defined codes for OS and file system types (TOPS-10 and, probably TOPS-20,
complain about unknown remote system types and generate bad directory listings so for
those systems it claims to be Ultrix-32).
On Nov 6, 2020, at 10:20 AM, Paul Koning
<paulkoning at comcast.net> wrote:
> On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt at softjar.se> wrote:
>
> On 2020-11-06 02:55, Paul Koning wrote:
>>> On Jun 29, 2020, at 8:45 PM, John Forecast <john at forecast.name>
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.
>> I've spent a bit of time with John's latest code to see how it works on
other platforms.
>> The answer is "quite nicely". I dropped his changed files into a
Fedora Core 32 (the latest release, as of a couple of weeks ago anyway) sources, and built
their 5.8.17 kernel with DECnet enabled, for 64-bit x86.
>> It works, no major problems seen. This is the endnode; I haven't tried a
router yet.
>> Very nice.
I?ve never even built the router version of the code. It is
marked ?experimental? in Linux config.
I had
serious problems using it to talk to RSX in the past (many years ago). Have you tried
accessing in both directions between an RSX node and that? It might be it has been
improved a lot since I tried, but I am a little concerned that it's mostly just been
tested against VMS.
You're right, the initial testing was against VMS, but it
wasn't all that long after that I spent a bunch of time getting it to work better with
others. For example, that's why the "old remote terminal protocol" is
implemented in Linux.
Just tried some tests.
RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works. DAP doesn't, it
gets "Tasks out of synchronization".
Linux to RSX: mirror works, cterm works, dap works.
RSTS to Linux: NCP works, LOOP NOD works, SET HOST works. DAP fails with a message
indicating an Interrupt message is mishandled. (DAP is one of the few protocols that uses
interrupts.)
Linux to RSTS: mirror works, cterm is not supported by RSTS, "sethost"
doesn't work because the connect fails in a way that doesn't reach the check for
"no such object" status. DAP partly works, but the directory listing only shows
the last file rather than all of them.
Haven't tried VMS yet, the VMS system I have access to seems to be down right now.
paul
John.
1:42 a.m.
On Nov 6, 2020, at 6:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
If you don't mind experimental code, you can anonymosly test it against my modified
Tops-20 DAP/FAL server.
It?s actually the other way round, TOPS-10 NFT talking to Linux FAL. I haven?t tested with
TOPS-20 yet but my understanding at the time was that both TOPS operating systems shared
common application level code. What version of DAP does your FAL server implement?
John.
You can contact me offline to set something up.
On 11/6/20 2:47 PM, John Forecast wrote:
>
>> On Nov 6, 2020, at 10:20 AM, Paul Koning <paulkoning at comcast.net>
wrote:
>>
>>
>>
>>> On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt at softjar.se>
wrote:
>>>
>>> On 2020-11-06 02:55, Paul Koning wrote:
>>>>> On Jun 29, 2020, at 8:45 PM, John Forecast <john at
forecast.name> 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.
>>>> I've spent a bit of time with John's latest code to see how it
works on other platforms.
>>>> The answer is "quite nicely". I dropped his changed files into
a Fedora Core 32 (the latest release, as of a couple of weeks ago anyway) sources, and
built their 5.8.17 kernel with DECnet enabled, for 64-bit x86.
>>>> It works, no major problems seen. This is the endnode; I haven't
tried a router yet.
>>>> Very nice.
> I?ve never even built the router version of the code. It is marked ?experimental? in
Linux config.
>
>>> I had serious problems using it to talk to RSX in the past (many years ago).
Have you tried accessing in both directions between an RSX node and that? It might be it
has been improved a lot since I tried, but I am a little concerned that it's mostly
just been tested against VMS.
>> You're right, the initial testing was against VMS, but it wasn't all that
long after that I spent a bunch of time getting it to work better with others. For
example, that's why the "old remote terminal protocol" is implemented in
Linux.
>>
> It also tries to pretend that it is VMS, both nml and fal. I?ve written new versions
of both; nml2 no longer responds to VMS system specific commands and fal2 mostly uses
user-defined codes for OS and file system types (TOPS-10 and, probably TOPS-20, complain
about unknown remote system types and generate bad directory listings so for those systems
it claims to be Ultrix-32).
>
>> Just tried some tests.
>>
>> RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works. DAP
doesn't, it gets "Tasks out of synchronization".
>>
>> Linux to RSX: mirror works, cterm works, dap works.
>>
>> RSTS to Linux: NCP works, LOOP NOD works, SET HOST works. DAP fails with a
message indicating an Interrupt message is mishandled. (DAP is one of the few protocols
that uses interrupts.)
>>
>> Linux to RSTS: mirror works, cterm is not supported by RSTS, "sethost"
doesn't work because the connect fails in a way that doesn't reach the check for
"no such object" status. DAP partly works, but the directory listing only shows
the last file rather than all of them.
>>
>> Haven't tried VMS yet, the VMS system I have access to seems to be down right
now.
>>
>> paul
>>
> John.
>
3:45 a.m.
No, the application code base is nothing alike; the monitor level code
is, oddly enough.
I don't know about NFT; it's on my list of DECnet utilities to fix.?
There appears to be a new file transfer facility implemented in BLISS
called FTS.? That might be shared, but it really doesn't seem to do much
of anything on PANDA.? I have yet to look at it; much of the other user
mode DECnet code is not really productized and I've been focused on that
(I.E., it's buggy).
However, it is impossible that DAP or FAL are shared.? FAL is
multi-forking, which Tops-10 cannot support (it actually runs FAL as
separate jobs off of Galaxy, which I think is a great idea). DAP is
completely Tops-20 based; it uses PMAP% (I.E., non-Tops-20 I/O).? I
strongly suspect that NFT does not share a common code base; at least
that's what I recall from the last time I was maintaining it in the 1980's.
I did have to make a few changes to DAP to keep it from confusing RSX.?
Johnny was a huge help there.? Tops-20 DAP is noticeably lacking RENAME;
it's something I want to put in, put I wanted ANONYMOUS first.
Both Tops-10 and Tops-20 use GLXLIB to implement certain functionality
(memory management comes to mind), but the respective Galaxies has
diverged over the years; in some cases, significantly.? They're clearly
from the same universe, though. (Boo)
Some of the monitor code is the same and has conditional assembly.? It
appears to have been debugged in user mode under Tops-10, then ported to
Tops-10 monitor mode and then ported to Tops-20 monitor mode.
I have a guest account on a very fine Tops-10 machine with source, but
I've only really looked at part of Galaxy thus far; not any DECnet
utilities.
On 11/6/20 7:42 PM, John Forecast wrote:
> On Nov 6, 2020, at 6:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
>
> If you don't mind experimental code, you can anonymosly test it against my
modified Tops-20 DAP/FAL server.
>
>
> It?s actually the other way round, TOPS-10 NFT talking to Linux FAL. I haven?t tested
with TOPS-20 yet but my understanding at the time was that both TOPS operating systems
shared common application level code. What version of DAP does your FAL server implement?
>
> John.
>
> You can contact me offline to set something up.
>
> On 11/6/20 2:47 PM, John Forecast wrote:
>>> On Nov 6, 2020, at 10:20 AM, Paul Koning <paulkoning at comcast.net>
wrote:
>>>
>>>
>>>
>>>> On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt at softjar.se>
wrote:
>>>>
>>>> On 2020-11-06 02:55, Paul Koning wrote:
>>>>>> On Jun 29, 2020, at 8:45 PM, John Forecast <john at
forecast.name> 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.
>>>>> I've spent a bit of time with John's latest code to see how
it works on other platforms.
>>>>> The answer is "quite nicely". I dropped his changed files
into a Fedora Core 32 (the latest release, as of a couple of weeks ago anyway) sources,
and built their 5.8.17 kernel with DECnet enabled, for 64-bit x86.
>>>>> It works, no major problems seen. This is the endnode; I haven't
tried a router yet.
>>>>> Very nice.
>> I?ve never even built the router version of the code. It is marked ?experimental?
in Linux config.
>>
>>>> I had serious problems using it to talk to RSX in the past (many years
ago). Have you tried accessing in both directions between an RSX node and that? It might
be it has been improved a lot since I tried, but I am a little concerned that it's
mostly just been tested against VMS.
>>> You're right, the initial testing was against VMS, but it wasn't all
that long after that I spent a bunch of time getting it to work better with others. For
example, that's why the "old remote terminal protocol" is implemented in
Linux.
>>>
>> It also tries to pretend that it is VMS, both nml and fal. I?ve written new
versions of both; nml2 no longer responds to VMS system specific commands and fal2 mostly
uses user-defined codes for OS and file system types (TOPS-10 and, probably TOPS-20,
complain about unknown remote system types and generate bad directory listings so for
those systems it claims to be Ultrix-32).
>>
>>> Just tried some tests.
>>>
>>> RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works. DAP
doesn't, it gets "Tasks out of synchronization".
>>>
>>> Linux to RSX: mirror works, cterm works, dap works.
>>>
>>> RSTS to Linux: NCP works, LOOP NOD works, SET HOST works. DAP fails with a
message indicating an Interrupt message is mishandled. (DAP is one of the few protocols
that uses interrupts.)
>>>
>>> Linux to RSTS: mirror works, cterm is not supported by RSTS,
"sethost" doesn't work because the connect fails in a way that doesn't
reach the check for "no such object" status. DAP partly works, but the
directory listing only shows the last file rather than all of them.
>>>
>>> Haven't tried VMS yet, the VMS system I have access to seems to be down
right now.
>>>
>>> paul
>>>
>> John.
>>
4:19 a.m.
Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
I have a guest account on a very fine Tops-10 machine with source, but
I've only really looked at part of Galaxy thus far; not any DECnet
utilities.
If somebody else wants an account on the same TOPS-10 system for testing, let me know.
I have other shiny baubles occupying my attention now, otherwise I'd do it.
Bob
12:51 a.m.
On 2020-11-06 20:47, John Forecast wrote:
I don't think RSX do any special handling independent of what kind of
remote system, but I can check a bit more if wanted. One thing that I
like, though, is that RSX can tell what the remote system identifies as:
.nft legato::/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11
DC=Yes
Remote FAL V5 DAP V7.2 Buffer size= 2064. OS=VAX/VMS FS=RMS-32
DC=Yes
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 6, 2020, at 10:20 AM, Paul Koning
<paulkoning at comcast.net> wrote:
It also tries to pretend that it is VMS, both nml and fal. I?ve written new versions of
both; nml2 no longer responds to VMS system specific commands and fal2 mostly uses
user-defined codes for OS and file system types (TOPS-10 and, probably TOPS-20, complain
about unknown remote system types and generate bad directory listings so for those systems
it claims to be Ultrix-32). I had serious problems using it to talk to RSX in
the past (many years ago). Have you tried accessing in both directions between an RSX node
and that? It might be it has been improved a lot since I tried, but I am a little
concerned that it's mostly just been tested against VMS.
You're right, the initial testing was against VMS, but it wasn't all that long
after that I spent a bunch of time getting it to work better with others. For example,
that's why the "old remote terminal protocol" is implemented in Linux.
1269
days inactive
1399
days old
26 comments
11 participants
participants (11)
-
bob＠jfcl.com -
bqt＠softjar.se -
djm＠wiz.net.au -
drb＠msu.edu -
gregg.drwho8＠gmail.com -
john＠forecast.name -
johnhreinhardt＠thereinhardts.org -
paulkoning＠comcast.net -
supratim＠riseup.net -
tommytimesharing＠gmail.com -
wilson＠dbit.com