For all those who have tunnels to my Cisco 1841, I have switched ISPs and
as such my static IP address has changed. In my configuration I have the
following endpoints configured:
David Moylan (Area 35)
Tomas Prybil (Area 34)
Supratim Sanyal (Area 31)
Brian Hechinger (Area 52)
Ian McLaughlin (Area 42)
Cory Smelosky (Area 9)
Dave McGuire (Area 61)
Peter Lothberg (Area 59)
Mark Darvill (Area 22)
Mark G Thomas (Area 23)
If you are on that list could you please update your tunnel to use my new
address, which is 163.47.57.118.
Mark Berryman, my IPv6 address is unchanged, for the moment.
Regards, Tim.
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.
L.S.
You a true altruistic wonder these days to have around :)
A king, sitting on his coffers chockfull of goodies, waiting to dispense them lavishly among the lesser endowed fellow users ....
Usually with kings it is the other way around as can be seen so often today.
Are the other set host varieties on MIM also endowed with workable patches?
We'll play copycat then, ... until better times will arrive.
Thanks ever so much,
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, 26 August, 2020 22:02
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Configuring py-decnet.
Aw, shit! (Excuse my language.)
I had more or less forgotten. Yes, as distributed, it has a bug. I have fixed it, but of course, noone else have that.
For now, the simple solution, pick MIM::DU:[5,54]RRS.TSK, and you'll be good.
Sigh! I really hope the whole DEC/Mentec/HP ownership mess can be sorted one day. I have about 100 fixes or improvements to RSX sitting...
Johnny
On 2020-08-26 21:57, R. Voorhorst wrote:
> L.S.
>
>
> Is there something different with patch levels or otherwise?
>
> After successful login on Rsts 10.1:
>
> $ logout
> SAVED ALL DISK FILES ON SY: 6784 BLOCKS IN USE JOB 7 USER 1,2 LOGGED
> OFF KB24: AT 26-AUG-20 21:53
> 6 OTHER USERS STILL LOGGED IN UNDER THIS ACCOUNT SYSTEM RSTS V10.1-L
> RSTS/E V10.1 RUN TIME WAS .2 SECONDS ELAPSED TIME WAS 1 MINUTE GOOD
> EVENING
>
>
>
>
>
>
> SWBU01::RRS -- Remote disconnect
>
> SWBU01::RRS -- Control returned to node SWBU01::
> MOV #20,R0
> EM:065126
> XDT>
>
>
> Best regards,
>
> Reindert
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> Sent: Wednesday, 26 August, 2020 15:09
> To: hecnet at Update.UU.SE
> Cc: Thord Nilson <thordn at gmail.com>
> Subject: Re: [HECnet] Configuring py-decnet.
>
> And to complement the picture a little more. On RSX, you need a program called RRS, which is provided among the "unsupported utilities" in the DECnet distribution.
>
> .rrs elvira
> MIM::RRS -- Connection established to node ELVIRA::
>
> RSTS V10.1-L 26-Aug-20 14:41
> User: 99,99
> PASSWORD:
>
> LAST INTERACTIVE LOGIN ON 26-AUG-20, 02:36 AT KB21:
>
>
> $
>
>
> Johnny
>
> On 2020-08-26 02:19, Thomas DeBellis wrote:
>> Yeah, that's what I found out, too.
>>
>> On Tops-20, the CTERM client is called CTERM-SERVER (don't ask)
>> whereas the NRT client is called SETHOST. SETHOST is /quite/ old and
>> I had been hacking it for efficiency and fixing a few bugs.
>>
>> It now has an alternate debugging entry to try to force Tops-20 NRT
>> (which will also work on Tops-10) and ignore the remote node type
>> until it can't proceed any further. Here are the results from my own
>> tests; they indicate that a CTERM (server) object does not exist on ELVIRA.
>> I'm not sure, but I had thought that CTERM had not been done on RSTS/E.
>>
>> !cterm-sERVER.EXE.2 elvira
>>
>> [Attempting a connection,
>> _CTERM Connect failed - Destination process does not exist_ !g
>> ds:sethost !ree Escape character(^Y):
>> Host name: ELVIRA::
>> [Connecting to remote host: ELVIRA]
>> _?RSTS/E type systems do not support Tops-20 NRT communications._
>>
>>
>> On 8/25/20 8:09 PM, Paul Koning wrote:
>>> John,
>>>
>>> Some systems, like VMS, will use CTERM by default, and there isn't a CTERM listener on RSTS. So you have to tell it to use the "old protocol", whatever that involves on your OS.
>>>
>>> paul
>>>
>>>> On Aug 25, 2020, at 7:24 PM,jy at xtra.co.nz wrote:
>>>>
>>>> Hi Thord,
>>>>
>>>> Congratulations, I can see you're up at:
>>>>
>>>> http://akdesign.dyndns.org:8080/map/data
>>>>
>>>> I just tried a set host elvira and set hsot 59.53 but I'm getting "network object unknown at remote node".
>>>>
>>>> Cheers, John
>>>>
>>>>
>>>>
>>>>> On 26 August 2020 at 11:14 Thord Nilson<thordn at gmail.com> wrote:
>>>>>
>>>>> Hi all!
>>>>> Update!
>>>>> Basic connections are now working, so for a limited time you can:
>>>>> set host elvira::
>>>>> login as 99,99 psw: testing
>>>>> Nothing much to see though.
>>>>> Thanks to all for your help!
>>>>>
>>>>> /Thord.
>
--
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
If you are running a standard PANDA distribution, then DDT is in the
monitor and you may fail to it.? Did it come up?? Did you do an examine
from the KLH10 micro-engine to see what instruction it was failing on??
Did you see what module it is failing in?
My monitor is modified from the base PANDA distribution to include
several local enhancements, so when I looked at that address, it showed
up as in the entry of CHKOPC, which is what is checking for differed
closes on virtual circuits.? This is in PHYKLP which is the KLIPA driver
(a.k.a. the CI).? Since KLH10 (sadly) does not implement the CI, there
is no way you should be executing in that module as there nothing for it
to talk to.
Moreover, there is no JRST 4 there.? So probably you have something else
at that address.
I have been running KLH10 for a /very/ long time; since late December
2002 and have made modifications there, too to fix an issue with locking
memory and to better support Linux (recent Ubuntu).? It is remarkably
robust; despite intensive development, I have stayed up well over a year
at a time (I.E., hit UP2LNG BUGHLT's)
I have found one problem; if you are running it on an _extremely_ fast
machine with SSD storage (in other words, you're basically never waiting
for anything) and you seriously beat on the file system, then the
keep-alive counter can get out of sync with the 20 thinking the front
end has died and the KLH10 DTE simulator apparently not understanding
what to do.
The 20 typed an initial BUGCHK and then in the middle of the second one,
it hangs waiting for the front end.
It's on my list of things to investigate.
> ------------------------------------------------------------------------
> On 8/31/20 4:15 PM, Supratim Sanyal wrote:
>
> hi all - my panda distribution instance is halting after a couple of
> days with the following message. is this a known problem for which
> there is some workaround?
>
> Monitor RF434E DEC10 Development
> System uptime 52:10:47
> Current date/time Wednesday 29-Jul-120 6:01:04
>
> [HALTED: Program Halt, PC = 22013]
>
> thanks
>
> Supratim
>
hi all - my panda distribution instance is halting after a couple of
days with the following message. is this a known problem for which there
is some workaround?
Monitor RF434E DEC10 Development
System uptime 52:10:47
Current date/time Wednesday 29-Jul-120 6:01:04
[HALTED: Program Halt, PC = 22013]
thanks
Supratim
Hello all!
I am trying to test up decnet iv on a rsts/e 10.1 system on simh and
hopefully connect to hecnet. Currently borrowing a node name/number from
Peter L.
Is the following setup workable/suitable?
rsts/e --> delqua --> virtual tap ethernet --> pydecnet --> real-ethernet
--> GRE tunnel.
Anyone who has done this and willing to share the setup used?
Or any good links?
I have not found a decnet-iv manual for rsts/e online, but maybe the rsx
manuals are usable. Anyone know?
Best regards,
Thord.
Hi Thomas,
How are your patches related to the Panda distribution?
Based upon as a reference or unrelated?
There are a lot of cross platform problems within fal for instance like in Tops10,
Best regards,
Reindert
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis
Sent: Wednesday, 26 August, 2020 22:44
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Configuring py-decnet.
You and me both!
I have over a 130 documented fixes and enhancements to Tops-20, some of them massive. This does not include what I've completely rewritten from scratch. Several items are in active development.
Yet I have no idea who I'd give them to. A few might interest XKL, perhaps. I guess I'll do something Github, one of these days.
I wore out all my vulgar language when Jupiter was cancelled. Seems like it's all 'Darn it', 'Golly' and 'Gee whiz' these days.
_____
On 8/26/20 4:02 PM, Johnny Billquist wrote:
Aw, shit! (Excuse my language.)
I had more or less forgotten. Yes, as distributed, it has a bug. I have fixed it, but of course, noone else have that.
For now, the simple solution, pick MIM::DU:[5,54]RRS.TSK, and you'll be good.
Sigh! I really hope the whole DEC/Mentec/HP ownership mess can be sorted one day. I have about 100 fixes or improvements to RSX sitting...
Johnny
_____
On 2020-08-26 21:57, R. Voorhorst wrote:
L.S.
Is there something different with patch levels or otherwise?
After successful login on Rsts 10.1:
$ logout
SAVED ALL DISK FILES ON SY: 6784 BLOCKS IN USE
JOB 7 USER 1,2 LOGGED OFF KB24: AT 26-AUG-20 21:53
6 OTHER USERS STILL LOGGED IN UNDER THIS ACCOUNT
SYSTEM RSTS V10.1-L RSTS/E V10.1
RUN TIME WAS .2 SECONDS
ELAPSED TIME WAS 1 MINUTE
GOOD EVENING
SWBU01::RRS -- Remote disconnect
SWBU01::RRS -- Control returned to node SWBU01::
MOV #20,R0
EM:065126
XDT>
Best regards,
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, 26 August, 2020 15:09
To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
Cc: Thord Nilson <mailto:thordn at gmail.com> <thordn at gmail.com>
Subject: Re: [HECnet] Configuring py-decnet.
And to complement the picture a little more. On RSX, you need a program called RRS, which is provided among the "unsupported utilities" in the DECnet distribution.
.rrs elvira
MIM::RRS -- Connection established to node ELVIRA::
RSTS V10.1-L 26-Aug-20 14:41
User: 99,99
PASSWORD:
LAST INTERACTIVE LOGIN ON 26-AUG-20, 02:36 AT KB21:
$
Johnny
On 2020-08-26 02:19, Thomas DeBellis wrote:
Yeah, that's what I found out, too.
On Tops-20, the CTERM client is called CTERM-SERVER (don't ask)
whereas the NRT client is called SETHOST. SETHOST is /quite/ old and
I had been hacking it for efficiency and fixing a few bugs.
It now has an alternate debugging entry to try to force Tops-20 NRT
(which will also work on Tops-10) and ignore the remote node type
until it can't proceed any further. Here are the results from my own
tests; they indicate that a CTERM (server) object does not exist on ELVIRA.
I'm not sure, but I had thought that CTERM had not been done on RSTS/E.
!cterm-sERVER.EXE.2 elvira
[Attempting a connection,
_CTERM Connect failed - Destination process does not exist_ !g
ds:sethost !ree Escape character(^Y):
Host name: ELVIRA::
[Connecting to remote host: ELVIRA]
_?RSTS/E type systems do not support Tops-20 NRT communications._
On 8/25/20 8:09 PM, Paul Koning wrote:
John,
Some systems, like VMS, will use CTERM by default, and there isn't a CTERM listener on RSTS. So you have to tell it to use the "old protocol", whatever that involves on your OS.
paul
On Aug 25, 2020, at 7:24 PM,jy at xtra.co.nz <mailto:jy at xtra.co.nz> wrote:
Hi Thord,
Congratulations, I can see you're up at:
http://akdesign.dyndns.org:8080/map/data
I just tried a set host elvira and set hsot 59.53 but I'm getting "network object unknown at remote node".
Cheers, John
On 26 August 2020 at 11:14 Thord Nilson <mailto:thordn at gmail.com> <thordn at gmail.com> wrote:
Hi all!
Update!
Basic connections are now working, so for a limited time you can:
set host elvira::
login as 99,99 psw: testing
Nothing much to see though.
Thanks to all for your help!
/Thord.
Hi all,
I'm working on a connection from an OpenVMS 7.3 emulation currently running DECnet and MultiNet, to the HNET using JNET 3.6.
I'm stuck with the following after starting JNET:
$ @JAN_DEVICE:[JANCOMMON.SYS]JANSTART
%JCP-I-CREATE, Creating new Jnet database of 159 pages
$
%%%%%%%%%%% OPCOM 27-AUG-2020 15:52:14.00 %%%%%%%%%%%
Message from user SYSTEM on GLOVER
Jnet status message from link NZVAX001
Unexpected Jnet daemon termination for link: Unknown:
%RMS-E-FNF, file not found
And JNET isn't attempting to open a TCP connect to the HNET peer. The JENT install went OK and I've carefully cross checked my config files with Supratim who has been very helpful.
I appreciate this is a bit off topic for this reflector so if anyone has experience with JNET and time to help, I'd appreciate a contact off list. My email is jy at xtra.co.nz mailto:jy at xtra.co.nz
Thanks, John
I just made some small changes to the DECnet/E event logger application to fix a Y2K problem. (More precisely, a Y2K.003 problem).
https://github.com/pkoning2/decstuff
This is for RSTS V10.1. Just drop the new evtlog.tsk into [0,16].
paul
Paul,
I?m pretty sure this is you. It?s coming from 28nh (41.28). What is it expecting? I seem to remember a discussion on this, but can?t find it in my archives.
Thanks,
Zane
