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
I was writing a routine to break out DAP flag bits to aid debugging when
I noticed a possible discrepancy between DAP V5.6 and Tops-20, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B28
DAP V5.6 reserves bit 4 and defines bit 6 to flag that a segmented
message is being sent and that this is not the last message. In other
words, that there will be another message. Tops-20 is using bit 4 for
this purpose and by rights it would appear that it should be using bit 6.
I will go see if I can't scare up what Tops-10 is doing, but I was
wondering if anyone knew what other OS's are doing.
Tops-20 NFT, FAL and NRT will do something called Poor Man's Routing (or
PMR, for short). The Tops-10 NRT client will also do it. PMR is
something I dimly recall from Phase II or III; this was back before 36
bit hosts could do full routing. Here is some background:
On CCnet, we had enough 20's that not all could be connected to each
other in a star network. Not even Columbia had enough KMC's to 'star'
our 20's; the closest we got was a ring. CMU had even more. When a 20
wasn't next door to whatever system you wanted to get to, you had SET
HOST to one that did and then do another SET HOST accordingly. Or maybe
you had to do that a few times.
The manual procedure and all the accounts involved was clunky enough
that pretty much only systems staff did this. It was out of the
question for researchers and paying customers.
So I /think/ some site on CCnet came up with the idea of automating it
to a certain extent. It was called "Poor Man's Routing" and the way it
worked is that you specified the route to the system in question. Let's
say you were on NODE*A*:: and wanted to go to NODE*C*:: yet did not have
direct connectivity. If both NODE*A*:: and NODE*C*:: had connectivity
to NODE*B*::, then the relevant part of the configuration looked
something like this:
NODE*A*:: ↔NODE*B*:: ↔NODE*C*::
If NODE*B*:: was a PMR host, then you could do something like SET HOST
NODE*B*::NODE*C*:: and the parser would convert this to some
intermediate string. Instead of opening a connection on DECnet object
23, it would use object 123 and NODE*B*:: was responsible for taking the
rest of the string and getting you to the right place.
It worked well enough if the systems in question weren't excessively
loaded (which was invariably /never/ the case) and it saved us when the
dates for version 6 slipped. I had been under the impression that some
site on CCnet had done this and remember eagerly flushing all of it when
we finished the field test.
Much to my surprise an acquaintance of mine at Marlboro (Larry Campbell)
formalized this with a separate module called DNCONN.MAC. I put this
into a conditional assembly in part to save some address space (only to
get blown out of the water by some vestigial code that had never been hit).
Does anybody remember PMR? Did it exist for the other systems which
supported DECnet? Just curious whether I should turn this on for anyone.
PS: So much for my silly subject line of the day...
In TCP, something called the 'push flag' can be set to cause accumulated
data in the monitor (which may be one or more packets) to be sent over
the network. It is often abbreviated as "PSH".
The Tops-20 FTP client and server both set PSH on the last packet of
data from a file to send it on its way. This is done with a SOUTR% JSYS,
which stands for *S*tring *OUT* *R*ecord. This is an overloading of the
hardware record concept which is more commonly associated with
nine-track magnetic tape.
PSH can also be detected on input by doing a SINR%, which stops the
network read early, instead of waiting for a full buffer of data (which
might, in fact, never come).
I believe DECnet transport implements the same semantics, but I would
like to double check that. Where would I go in which part of what
specification? Or does anybody know?
I recently had a number of connectivity issues that caused me to review
my DECnet related batch jobs. The following is a snippet from the log
file of GETNOD, which is the weekly batch job that fetches the latest
HECnet node list from MIM::. I had updated it in part because of
trouble-shooting, but the change isn't dramatic--it's rather more of a
'buff and polish'. The items in red are of note:
20:31:21 MONTRÂ Â $@NFT
20:31:21 USERÂ Â NFT>*SET DEFAULTS MIM:: /USER:
20:31:21 USERÂ Â NFT>*SET DEFAULTS MIM:: /PASSWORD:
20:31:21 USERÂ Â NFT>*SET DEFAULTS MIM:: /ACCOUNT:
20:31:21 USERÂ Â NFT>*SET DEFAULTS MIM:: /OSTYPE:RSX11Â ;<-- NEW
20:31:21 USERÂ Â NFT>*DIR MIM::FIX.T20;0
20:31:21 USER
20:31:21 USERÂ Â [Fork NFT opening DCN:MIM-FAL for reading, writing]
20:31:23 USER %Remote OS type /different/ from that specified with
SET DEFAULT
20:31:23 USER
20:31:23 USERÂ Â Â Â MIM::DU1:[DECNET]
20:31:23 USERÂ Â FIX.T20;161;P775656Â Â Â Â Â Â Â Â Â Â Â Â 18 35840(8)
18-Oct-2022 09:59:43
There is nothing fatal about the message, but it was surprising.
Investigating the parse table for OSTYPE in NFT.MAC shows:
OSTTBL: XWD OSTSIZ,OSTSIZÂ Â Â Â Â Â Â Â Â Â Â Â Â Â ;ARGUMENTS FOR /OSTYPE
       T (IAS,.OSIAS)                 ;Operating system type
;Â Â Â Â Â Â T (OS-8,.OSOS8)
       T (RSTS,.OSRST)
       T (RSX11,.OSRXM)
       T (RT11,.OSRT)
       T (TOPS10,.OSTP10)
       T (TOPS20,.OSTP20)
       T (VMS,.OSVAX)
So the above shows only a single RSX parse item and I had wondered about
that, given all the various flavors of RSX. Further investigation into
DAPSYM.MAC shows what Tops-20 DAP actually knows about (in octal).
       .OSRT==1       ;RT-11
       .OSRST==2      ;RSTS/E
       .OSRXS==3      ;RSX-11S
       .OSRXM==4      ;RSX-11M
       .OSRXD==5      ;RSX-11D
       .OSIAS==6      ;IAS
       .OSVAX==7      ;VAX/VMS
       .OSTP20==10    ;TOPS-20
       .OSTP10==11    ;TOPS-10
       .OSOS8==12     ;OS-8
       .OSRXP==13     ;RSX11-M PLUS
That's more like it, I would assume. So I guess the fix here is to put
a few more entries into the NFT parse table.
Johnny, which one of the above is MIM:: reporting? I guess 13?
Hi,
Is anybody out there using PyDECnet and GRE over IPv6 who would be willing to set up a circuit between A29RT2 (29.2) and their router?
Regards
Keith
