HECnet September 2020

hecnet@lists.dfupdate.se

24 participants
15 discussions

by tim＠sneddon.id.au

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.

3 years, 2 months

DECnet for Linux Bug Fixes

by john＠forecast.name

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.

3 years, 5 months

Booting VMS 5.5.2 cluster satellite node [SIMH 4.0] over slow link

by xdelta＠meta.ua

Hi, guys! I'm trying to boot latest SIMH (4.0-current) as LAVC satellite node over link with latency about 100ms. Boot node is VAX/VMS 5.5.2 with latest PEDRIVER ECO. Result: MOP part of boot sequence is work without a hitch, but SCS part is failing miserably. The most frequent result: SIMH console filled with 10 x " %VAXcluster-W-NOCONN, No connection to disk server " messages, halting with "%VAXcluster-F-CTRLERR, boot driver virtual circuit to SCSSYSTEM 0000 Failed" Sometime it goes little further: ... %VAXcluster-W-RETRY, Attempting to reconnect to a disk server %VAXcluster-W-NOCONN, No connection to disk server %VAXcluster-W-RETRY, Attempting to reconnect to a disk server %VAXcluster-W-NOCONN, No connection to disk server VULCAN %VAXcluster-W-RETRY, Attempting to reconnect to a disk server %VAXcluster-W-NOCONN, No connection to disk server %VAXcluster-W-RETRY, Attempting to reconnect to a disk server %VAXcluster-I-CONN, Connected to disk server VULCAN %VAXcluster-W-NOCONN, No connection to disk server VULCAN %VAXcluster-W-RETRY, Attempting to reconnect to a disk server ... And halting after minute or so of filling console with those messages. Whenever I setup throttling in SIMH to 2500K ops/s, the node boots successfully, joins cluster successfully and work flawlessly, but slow. Boot process takes about half hour. After boot, changing throttle value to 3500K ops/s still works. Increasing throttle value further broke system, with the same messages about disk server. Throttled SIMH performance is about 5VUPS. The only information about maximum channel latency restrictions found in "Guidelines for OpenVMS Cluster Configurations" manual is that: "When an FDDI is used for OpenVMS Cluster communications, the ring latency when the FDDI ring is idle should not exceed 400 ms." So I suppose that 100ms latency link should be good enough for booting satellite nodes over it. My understanding of situation is that combination of PEDRIVER/[PEBTDRIVER within NISCS_LOAD] with fast hardware and slow links is a primary reason of such behavior. Please correct me if I'm wrong. Do anyone have experience with booting VMS clusters over slow links? OS version recommendations? Probably some VMS tunable variables are exists for making PEDRIVER happy on fast hardware? Having PEDRIVER listings can shed lights for such PEDRIVER's buggy behavior. Link details: Two Cisco 1861 routers connected with Internet via ADSL on one side and 3G HSDPA on other side. TCP/IP between sites is routed over IPSec site-to-site VPN. Ping between sites is about 100ms. Over that VPN built DECnet family (eth.type = 0x6000..0x600F) bridge with L2TPv3 VPN. -- BR, Vladimir Machulsky

3 years, 6 months

Question for PyDECnet users

by paulkoning＠comcast.net

Gentlepeople, Currently the details of what PyDECnet circuits connect to are not displayed. So you can see that a Multinet circuit is up and the other end is node 42.73, but you don't see the IP addresses or the like. When things are working that's fine; when they are broken it might be helpful to see what something is trying to talk to. On the other hand, hiding IP addresses is arguably a security feature. So I have this question: 1. Should the addressing info (basically, what's in the --device config argument) be shown in the PyDECnet web interface? 2. Should the addressing info be visible via NCP / NML? The difference is that #1 can be limited to be local only, if you use an internal address for the web service. That's what I do for my nodes except for the mapper, though perhaps there isn't a strong argument why it should be so restrictive. #2, on the other hand, is visible to all HECnet users assuming you haven't disabled NML in your config settings. I'd be interested in comments. Am I too concerned about hiding information, or is it sensible to be cautious? paul

3 years, 6 months

RSTS/E patches

by paulkoning＠comcast.net

I previously created a Github repository for various DEC things, including updated DECnet/E utilities. I thought that the RSTS patches I had posted in the past were there also, but that wasn't the case. I've added a "patches" subdirectory, which contains the patches I have collected. I just added a new one, which fixes a bug encountered when running SIMH set to be an 11/94. In that case (and possibly some other similar variations) RSTS tries to figure out the line frequency and gets it wrong because SIMH executes much faster. https://github.com/pkoning2/decstuff is the repository. paul

3 years, 7 months

RSTS/E patches

by paulkoning＠comcast.net

The patches I posted are mostly for both. The kdj11e.cmd patch is for a problem seen on SIMH that probably can't happen on real hardware. The nsp1.pat file Tony mentioned is certainly more likely on SIMH but I suspect could happen on real hardware also. In any case, none of them will create problems on real hardware. paul > On Sep 15, 2020, at 9:20 AM, W2HX via cctalk <cctalk at classiccmp.org> wrote: > > Are these patches discussed below only for patching SIMH to fix problems with it? Or are these fixes that are for actual PDP hardware implementations of RSTS? > > -----Original Message----- > From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Tony Nicholson via cctalk > Sent: Monday, September 14, 2020 6:10 PM > To: hecnet at update.uu.se > Cc: cctalk at classiccmp.org > Subject: Re: [HECnet] RSTS/E patches > > On Tue, Sep 15, 2020 at 7:28 AM Paul Koning <paulkoning at comcast.net> wrote: > >> I previously created a Github repository for various DEC things, >> including updated DECnet/E utilities. I thought that the RSTS patches >> I had posted in the past were there also, but that wasn't the case. >> >> I've added a "patches" subdirectory, which contains the patches I have >> collected. I just added a new one, which fixes a bug encountered when >> running SIMH set to be an 11/94. In that case (and possibly some >> other similar variations) RSTS tries to figure out the line frequency >> and gets it wrong because SIMH executes much faster. >> >> https://github.com/pkoning2/decstuff is the repository. >> >> paul >> >> > Thanks for this Paul. > > There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under SIMH (posted to the SIMH mailing list in May 2016). > > You'll find it and the NSP1.TXT describing it in my repository at > > https://github.com/agn453/RSTS-E > > in the "decnete" subdirectory. > > I've recently joined HECnet and will be making some of my updates available soon. > > Tony > > -- > Tony Nicholson <tony.nicholson at computer.org>

3 years, 7 months

Some RSTS/E files on HECnet node DINGO::

by tony.nicholson＠computer.org

I've just thrown together the RSTS/E updates mentioned in my previous message into the DECnet default account on HECnet node DINGO:: (35.619) The file DINGO::FILES.TXT contains the following details (and will be added to as I make available more files). === FILES.TXT == These are the files available from HECnet node DINGO:: (a SIMH PDP-11/70 emulation running RSTS/E V10.1 on a Raspberry Pi 3B) in the Default DECnet account (no password required). There's also a GitHub repository at https://github.com/agn453/RSTS-E where you can get further RSTS/E related information (with a link to Paul Koning's repository too). Name .Typ Size Prot Access Date Time Clu RTS DINGO:: Patch for improved Ethernet throughput using DECnet/E V4.1 on RSTS/E V10.1 NSP1 .PAT 2 < 62> 03-May-16 03-May-16 08:38 AM 64 ...RSX NSP1 .TXT 9 < 62> 19-Sep-16 19-Sep-16 02:29 PM 64 ...RSX Year 2003 update for FIT (File Interchange Transfer program) FIT .TSK 92C < 62> 03-Jul-20 03-Jul-20 02:09 PM 64 RSX FIT .DIF 5 < 62> 02-Jul-20 02-Jul-20 07:49 AM 64 ...RSX FITBLD.COM 2 < 62> 03-Jul-20 03-Jul-20 08:09 AM 64 DCL This file FILES .TXT 2 < 60> 15-Sep-20 15-Sep-20 09:31 AM 64 RT11 A directory of Kermit-11 T3.63 files (with updates to 3-Oct-2006) available from DINGO::KERMIT: KERMIT.TXT 35 < 60> 15-Sep-20 15-Sep-20 09:32 AM 64 RT11 Please report any problems to me via e-mail to either tony.nicholson at computer.org or (HECnet) FAUNA::TONY -- Tony Nicholson <tony.nicholson at computer.org>

3 years, 7 months

integrity and alpha hardware

by system＠TMESIS.COM

Peter Lothberg <roll at stupi.com> writes: >Yes, it says DEC on some on Compac on some. The DS20 diagnostics and >microcode update CD works on it. What does it say in the SRM? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

3 years, 7 months

Introducing some Australian fauna to HECnet

by tony.nicholson＠computer.org

G'day fellow HECnet enthusiasts! In the past week I decided to jump in and join up my little home network of Digital animals to HECnet. With the assistance of Johnny Billquist, David Moylan (Wiz) and the brilliant piece of PyDECnet routing code by Paul Koning running on a Raspberry Pi - I'm now up and online! You'll see my machines pop up as 35.6xx nodes; and, as soon as I organise things, I'll put some files up for perusal in the default DECnet accounts - (they're empty now though). I'm located at Newcastle, NSW in Australia and nudging over 45 years contact with systems from PDP-11's through VAXen and on to Alpha... along with various Cisco, Sun, CDC3500, ICL1904A, HP2100, HP1000 systems plus microcomputers from the 8080, SC/MP, Z80 era up to now. Johnny says I have "quite a list" of machines.. so I'll give a partial list here (node names in brackets) - RSTS/E V10.1 running on Raspberry Pis under SIMH PDP11 (DINGO and GALAH) - the latter is a PiDP11 mini 11/70 front panel. RSX11M-Plus V4.6 running on the same Raspberry Pi as DINGO under SIMH PDP11 (RUSTY) OpenVMS VAX V7.3 on a Vaxstation-3100 M48 (POSSUM) - which is showing its age with a power-supply fault since yesterday! An original DEC-2000 AXP model 300 (TAIPAN) just freshly upgraded to VSI OpenVMS V8.4-2L1 A VAX-11/780 SIMH emulation running OpenVMS V5.5-2 on Raspberry Pi (EMU) Intermittently I also fire up emulations running Ultrix-32 VAX V4.6 (NUMBAT), TRU-64 V5.1B (QUOLL), "ancient" VAX/VMS from V1.5 to V4.7 (BROLGA), TOPS10 V7.04 (PANDA) - and P/OS V3.2 one day when I get a round 'tuit (DUGONG) with Xhomer Pro-380 emulation and async DECnet. Finally a couple that are nearly always online - An Alpha ES40 emulation (KOALA) under AlphaVM-Free running VSI OpenVMS V8.4-2L1 on an Intel Core i7 Windows-10 box, and VAXserver-3900 SIMH with OpenVMS VAX V7.3 under Windows-10/Cygwin-32 (VOGON). You can reach me at FAUNA::TONY if you want to try e-mail the old fashioned way from VAX-MAIL or Mail-11. Tony -- Tony Nicholson <tony.nicholson at computer.org>

3 years, 7 months

integrity and alpha hardware

by djm＠wiz.net.au

Greetings all, Now that VSI has their Hobbyist program all under way, we can get licensing for Integrity and Alpha hardware. (the future is obviously x86 which is progressing well and I'm looking very forward to. The hobbyist program will cover x86 once it has been released) I was thinking of trying to find an older Integrity or Alpha server to run OpenVMS but I'm struggling to find any real comparative performance comparison between the different models. Most of the old forum posts on HP link to dead articles. Alpha hardware still seems to be very high priced, but I'm starting to see some Integrity equipment coming down in price. How does something like an Integrity rx1620 stack up? Would there be any sense in purchasing a single CPU version of this server? If anyone has a list or can provide information on the different Integrity and Alpha platforms available that would be great. I totally understand that performance comparison is an "it depends" question, but I'm just after some reality checks here, ie: a specific Integrity server might have "twice" the average performance of a different Alpha box and it might be cheaper, thus better bang per buck. Can anyone help me out here? The box will just be for hobbyist purposes. I'll probably setup a mail gateway and perhaps usenet and some other things to play with. If it's relevant (for suggestions of anyone selling refurbed hardware), I'm located in Australia. Thanks in advance, Cheers, Wiz!!

3 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet September 2020