Yes, LEO was #1000. :-)
Johnny
On 2023-03-09 02:32, Brian Roth wrote:
> Wow, very cool. I was just looking at my Directory of computer networks
> at lunch the other day and scanning over the SPAN network from 1990.Its
> hard to believe just 30 years ago there was a worldwide DECnet network
> with over 17,000 computers, real machines doing real work. Its pretty
> cool to actually see in detail every machine type on SPAN (almost
> entirely DEC) , machine names, VMS version and even phone numbers. BTW
> was my machine LEO the 1000th?
>
>
> On Wednesday, March 8, 2023 at 03:47:26 PM EST, Johnny Billquist
> <bqt(a)softjar.se> wrote:
>
>
> I have been planning for a long time to post a small reflection when I
> reached 1000 nodes registered in the hecnet nodename database.
>
> This happened tonight. I think it is a pretty cool thing. There are now
> 1000 nodenames registered in this small hobby DECnet. I guess you could
> say it's actually not that small.
>
> However, I know that rather few machines are actually online, and it
> might even be that the majority of nodes registered have never been
> online. My guess is that maybe 5% of the registered machines are usually
> online. But I do not have any hard data to back this up.
>
> HECnet started out about 20 years ago from a desire I had to hook up a
> PDP-11 I had at home, to some machines at my university, using DECnet.
> At the time, I didn't have any TCP/IP for RSX, and the only way to get
> any kind of networking was to try and come up with some way of getting
> DECnet up.
>
> My first implementation basically just forwarded a serial port
> communication between two Unix machines. And on each end I then hooked
> that serial port into a PDP-11 running RSX, and used DDCMP for the
> actual DECnet link.
>
> This worked, but was obviously not that fast, as the serial ports were
> limited to 9600 bps.
>
> After a year or so, I figured I could instead write a small program that
> would forward ethernet packets. Using UDP I basically had the same
> property as a local ethernet, but it could be located somewhere pretty
> far away. From a DECnet point of view, it would appear as if they were
> on the same ethernet segment, while in reality they were nowhere near.
> As DECnet have pretty long timeouts on things, it turned out this worked
> without a hitch, and I could achieve much better throughput.
>
> Not long after that, the first other users were hooked up to HECnet as
> well. This was maybe around 2003 or so.
>
> Another data point is that there are 113 different persons that have one
> or more nodenames registered.
>
> Happy milestone, everyone, and thanks for being around.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt(a)softjar.se <mailto:bqt@softjar.se> || Reading
> murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> <mailto:hecnet@lists.dfupdate.se>
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
> <mailto:hecnet-leave@lists.dfupdate.se>
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hi,
I've just noticed that nodes 29.600-699 had been allocated to someone and they've since disappeared from the HECnet node database... or possibly I imagined the whole thing... except for the fact that I had an inbound multinet circuit for nodes in that range. I've just removed the circuit and the firewall ACL for incoming on TCP port 9604. The circuit hadn't been used in some time.
In no other particular order of peers:
29.400-403 (Ales Petan) has been gone a while.
29.450-469 (Trevor Warwick) similarly.
46.1-9 (Douglas Hall) has been gone for quite a long time.
52.* (Brian Hechinger) has been down for a few weeks... and has changed incoming IP address once or twice too.
I'm not complaining, just wondering. Known areas are going dark at a rate greater than 0 too.
Oh, and ANKE (1.1023) went >BANG< a few days ago.
Regards
Keith
Hi, I have a couple of strange issues on RSX-11M-PLUS with the latest TCP/IP stack (build 14-FEB-2023 00:19).
1) If I create a LB{1,2]SYSLOGIN.CMD with a couple of entries such as:
set /named
set /vt2xx=ti:
when I login, it executes the commands but then I can type nothing at all into the terminal screen, it is completely frozen.
2) When I try to send an e-mail (I think it is set up OK), it gives the following error:
>SEN
To: PETER.WHISKER(a)GMAIL.COM
Connection to local node:: failed,
CONN STATUS= 2 STATUS2= 0
SENT0 -- STOP ERROR
The [IPLOG]MAILD.LOG shows:
Sun, 19 Feb 2023 09:47:58 (MAI.0) MAIL11 got connection from CLIONA:: (Unknown M
AIL11 V3.0)
Sun, 19 Feb 2023 09:47:58 (MAI.0) Connection lost
I'm a bit lost as to how to debug this further - has anyone else encountered it or can Johnny shed any light?
Thanks
Peter Whisker
Hi,
I'm attempting to connect to the area 29 node and Keith Halewood has very helpfully set me up with a listener.
I've been getting a strange error on the Multinet link and updated to the latest BQ-IP from December 2022 before posting this. I continue to have the same problem after the update.
My IP stack is fine - I can ping and get the NTPDATE time and I can access my RSX11M system via Telnet.
The Node has the right area and number and I can access it from the other node using RMT.
However when I try to bring up the link to HECNet I keep getting this error repeating:
>NCP SET CIR IP-0-0 STA ON
14:29:03 COT -- Date is 13-FEB-2023
14:29:03 MLTNET V1.27 starting.
>
>
14:29:05 MLTNET - IP-0-0 XMIT fail. IOSB=-3
14:29:10 MLTNET - IP-0-0 XMIT fail. IOSB=-3
I can see the traffic leaving on my DSL router to the Area 29 router and the replies coming back. So I am bit mystified. I think IOSB error -3 is IE.DNR - Device not ready?
Node details:
>NCP SHO KNO NOD
Known nodes summary as of 13-FEB-2023 14:32:39
Executor node = 29.850 (CLIONA)
State = On, Identification = CLIONA RSX11M+ V4.6
Remote Active Next
Node State Links Delay Circuit Node
29.1 (A29RT1) Unreachable
29.2 (A29RT2) Unreachable
29.852 (SADHBH) Reachable UNA-0 29.852 (SADHBH)
Below is recent correspondence - I will post it hear as it may be helpful:
Hi
It’s set up as a “Level 2 router” – perhaps that is the problem? I’ve looped in Johnny in case he has an idea where the problem may be?
Regards
Peter
>; =====================================================================
>; DEC - Section 1 - Define the target and remote nodes
>; =====================================================================
>;
>; Generating node 29.850 (CLIONA), Id = CLIONA RSX11M+ V4.6
>; Node type is level 2 router
>; Highest node number in network is 1023
>; Highest area number in the network is 63
>; Network command terminal and layered product support will be included
>; The MACRO-11 and FORTRAN/COBOL/BASIC+2 user libraries will be supplied
>;
>; The remote node names are:
>; 29.852 (SADHBH)
>; 29.2 (A29RT2)
>; 29.1 (A29RT1)
>;
>; <EOS> Do you want to:
>* <RET>-Continue, S-Skip, R-Repeat section, P-Pause, E-Exit [S]:
>;
>;
From: Keith Halewood <Keith.Halewood(a)pitbulluk.org>
The only thing I can think of is DECnet with more than 1 interface needs to be an L1 router and not an endnode. Other than that, I’m not at all familiar with RSX and Johnny’s IP stack.
From: Peter Whisker [mailto:peter@whisker.org.uk]
I'm getting IOSB error -3 which I think may be IE.DNR Device not ready. I can see the IP traffic going out and back on the interfaces both sides of my router. I need to check if I've missed some DECnet configuration.
On Mon, 13 Feb 2023, 10:39 Keith Halewood, <Keith.Halewood(a)pitbulluk.org> wrote:
I can see your connection attempts. The DECnet router 29.2 is reporting ‘unexpected packet type’, adjacent node 29.850, packet header 01 29.850
Hi,
I have 20 years experience of PDP-11s and RSX-11M in particular which I haven't used much since 2000, so I have decided to brush up again and have spun up a couple of RSX-11M-PLUS 4.6 nodes in simh. They are happily chatting away over BQ-IP and LAT and I guess the next stage is to request a connection to HECnet. My two geographically nearest node areas are Northolt (UK) and London (UK) - both within 30km of me.
It looks like Northolt area 29 (Keith Halewood) might have a main routing node. London is in area 8 with admin Sampsa Laine. I'm just wondering if either of these areas allow new connections ot what is the best way to go?
Many thanks
Peter Whisker
Addlestone, Surrey UK.
FYI - AWS is doing maintenance on 2/27/2023 at 8AM GMT so A2RTR will be down. That's the middle of the night/very early morning for us here in the USA.
Bob
-----Original Message-----
From: Amazon Web Services, Inc. [mailto:no-reply-aws@amazon.com]
Sent: Friday, February 10, 2023 2:03 PM
To: bob(a)sparetimegizmos.com
Subject: Scheduled maintenance for Amazon Lightsail instances on Mon, 27 Feb 2023 08:00:00 GMT
Dear Amazon Lightsail Customer,
One or more of your Amazon Lightsail instances is scheduled for maintenance in a 2 hour window starting on Mon, 27 Feb 2023 08:00:00 GMT.
Maintenance activity will result in the following Lightsail instance(s) in the us-west-2 region to be unavailable and then rebooted:
HECnet
If you have any questions or concerns please contact the AWS Support Team on the community forums and via AWS Premium Support at: http://aws.amazon.com/support
Sincerely,
Amazon Lightsail Team
Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210
This is "mostly" on-topic, as I'm trying to get a friend on HECnet. ;)
Last night while putting together a system for a friend, I hit a VAX
networking problem. I wasted hours on it. I go way back with VAXen and
VMS, and have never seen anything like this. I need assistance.
The platform is a MicroVAX 3400 (KA640) with integrated Ethernet, and
a fresh install of VMS 7.3 with DECnet Phase-IV. I did nothing
different on this machine that I haven't done a thousand times before on
various VAXen.
The symptom is that the interface seems to be able to receive, but
not transmit. With LAT enabled, for example, it will see service
availability broadcasts, but it never sends any packets when trying to
establish an outbound connection. The MAC address table on the
(Cisco) switch never gets an entry for that machine.
The only thing that looked weird to me was the Ethernet interface
device names. The template device for the Ethernet interface is ESA0,
and I'd expected for the cloned devices for NETACP and LATACP to have
been ESA1 and ESA2, but they turned out to be ESA3 and ESA4, with no
ESA1 or ESA2 clones in existence. I'm not convinced that it's a
problem, but it seemed odd.
We tried two copies of every piece of hardware: chassis/PS, boards,
cab kits, cables, switch ports on the other end, etc.
I no longer have the system here, but will try to arrange for remote
console access soon.
I've never been so baffled (or frustrated) about a VMS networking
issue. Does anyone have any ideas about this?
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I had a bit of a go-around with Comcast over the weekend. The end result is that my addresses have changed. If you are one of my HECnet neighbors, my new addresses are:
IPv4: 73.95.34.4
IPv6: 2601:281:c100:6d0:3870:e9fa:b78e:abd2
These are also always available in DNS as decnet.theberrymans.com.
Mark Berryman
Area 27
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.11 of BQTCP/IP.
It's been eight months since the last official update. Some major
improvements and bugfixes have been done, and it is strongly recommended
that systems are updated. Some of the errors fixed could cause system
crashes under the right conditions.
Highlights:
. Improved TCP performance
. Added better error messages to FTP/FTPD as well as more features and
better handling.
Detailed information on things that have been done since the last release:
TCP:
. Corrected checksum computation. Checksum values of 0 should be
replaced by -1.
. Improved TCP retransmit strategy.
. Improved TCP NVT send processing code.
. Improved TCP receive packet sequence number processing.
TELNETD:
. Improved telnet server to handle abort as stop accepting new
connections, and exit when the last existing connection is closed.
FTP/FTPD:
. Improved error messages from failed file operations in FTP/FTPD.
. Changed FTP GET command to issue SIZE before PORT/PASV/EPSV
. Changed FTPD RETR command to not push after file attributes.
. Added MDTM command to FTPD.
. Improved error messages on failed FTP OPEN command.
. Added handling of progress updates in FTP client so that it don't
possibly issue many QIOs.
LPT/LPQ:
. Added inhibit of task and session logical name table search for LPT/LPQ.
MAILD:
. Bugfix in MAILD logging for MAIL11SND. Remote string could get corrupted.
. Improved MAILD. At SMTP receive, if the remote host is bad, we
returned 550. Changed to 454, as host lookups is not a permanent error.
. Improved mail delivery logging.
. Added sender string as configuration to mail.
. Updated mailbox format.
. Improved mail error handling.
. Improved MAILD SMTP reception host filtering.
. Added ability to block mails from hosts with certain reverse DNS.
HTTPD:
. Added 400 response to http requests with no host header option.
. Made URL matching case insensitive in HTTPD.
. Improved processing of URLs in HTTPD.
MULTINET:
. Changed MULTINET to use nagle with immediate ACK.
RSX patches:
. Improved NCP as provided in RSX patches.
Installation:
. Improved installation procedure to handle installation from non-system
disk.
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are not critical, but will lead to a much better experience,
and might avoid system crashes in rare circumstances.
The patches to the TT: driver cannot be applied automatically, but
requires users to apply the patches themselves, and then run SYSGEN to
generate a new system.
Once added, the TNC2 task can be run at login, and will define logical
names for the user telling where he is connected from, if using telnet
or LAT.
The TT: driver patches also allows the updated MCR to give more
information with the DEV command (SHOW TERMINAL in DCL).
The other patches to RSX can be applied automatically by IPGEN, either
if used interactively when answering YES to the question about applying
RSX patches, or by running IPGEN explicitly to do the patches, with the
command:
@IPGEN PATCH
Specific information about the patches:
LAT: Fixes a memory leak, and adds the ability to read where a terminal
connection comes from when using LAT, using SF.GMC.
RMSDAP: Fixes a bug in getting the file protection, so the XAB gets
filled in correctly for remote files.
RMSDSP: Fixes that some numbers were displayed in signed octal, which
should have been displayed in decimal or unsigned octal, depending on
number.
DCL: Added terminal attributes for COLOR.
MCR: Too many fixes to be listed here...
INS: Fixes that users cannot circumvent protection on common regions.
HEL: Fix that users can login with session ID, or with directory, in
addition to name and UIC.
ACNT: Add no password change attribute to accounts.
PSW: Add no password change handling.
SYL (SYSLOG): Add terminal idle tracking on accounts without idle logout.
ECL: If the receiving machine is very slow, and the sending machine is
very fast, and the receiver announce several large buffers available,
ECL cannot keep up, and drops packets. This is a problem with the DECnet
flow control, as it is used in RSX. The simple solution is to allow more
outstanding buffers when receiving. A more complex solution would be to
change how RSX DECnet do flow control, but that would require rewriting
a fair chunk of the ECL module.
NMVACP: Fix handling of "show known nodes" command, which could skip
some nodes.
NVP: Add ability to use session ID or directory name for user identity
in DECnet nodename specifications.
EPM: Fix handling of ethernet multicast.
NTDEMO: Fix that hosts without names should display DECnet address.
NCP: Parse of additional information types in NICE messages.
As usual, the distribution is available from:
ftp://mim.stupi.net/bqtcp.dskftp://mim.stupi.net/bqtcp.tap
!!! BQTCP is also available through RPM !!!
(As an additional note, if there are any problems communicating with Mim
using port 21, the ftp service is also available at port 10021)
The documentation is also available through ftp on Mim, or also at
http://mim.stupi.net/tcpipdoc
I hope people find this update useful.
Merry Christmas,
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
