So Mark (Matlock) has been after me to get my HECnet connection up and running and me, being an ace procrastinator, has always said "Real Soon Nowâ„¢", Mark.
I might actually have time to do it as I'm on vacation for a week and a half. Despite the heat I could set something up. My question is how do I set it up. I have a Mac Mini in Las Vegas running VMWare ESXi. I have a VM (Aniketos) running Vyos for a firewall/router, another VM with an Nginx web server (Hermes - irrelevant just mentioned for completeness) and a really small (1 vCPU) Linux VM (Knight) which I want to run Paul's PyDECnet router for the world to connect to. From there I have an IPSec VPN to my Ubiquiti EdgeRouter 4 at home. How can I connect DECnet through the VPN to Knight from home? Is it even possible? Do I need or want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet router at home and go that way through my dynamic IP? It's possible I could set up an x86 OpenVMS machine as another VM
I'm thinking I need a PyDECnet router at home to collect all the DECnet traffic and shove it through the VPN to the PyDECnet router at the remote site and from there out into the internet to it's HECnet connection points. Does that make sense?
I tried drawing an ASCII picture but apparently I suck at that. Hopefully the description makes sense.
Hoping to get people's thoughts and if you're experienced in designing PyDECnet config files, any pointers are welcome.
--
John H. Reinhardt
I'm moving in a few days and am trying to understand what to do about
connectivity without drowning (in advertising or whining).
I currently have FIOS and had ordered it so that I had a separate
Optical Network Terminal (ONT) and router. I plugged my own router into
the ONT and the FIOS router into my router and all has been well.
The Internet provider at the new location is Optimum Online which
previously had been a lot easier to deal with than FIOS as you could
just plug into the cable modem or get your own. Naturally, I was
provided with a combo ONT/Wireless/Router solution that just isn't going
to cut it. I'm trying to search for an ONT, but am getting deluged with
the usual stream of noise, junk and advertising. For example, I'm
getting Optical-Ethernet converters, which I don't think are what I want.
Can anybody point me at a few ONT-only solutions that don't come with
all the extra garbage, don't do NAT, Etc.? Or some kind of good
introductory information without all the blinking ads?
TOMMYT:: [2.520] and VENTI2:: [2.522] will be offline for a few days
towards the end of the week.
The problem with the OO gear is that there is no bridge mode and that I
will be double nat'ed, which makes a number of things hard.
A business connection has been out of the question for some time; it's
really bring your wallet...
The OO website says you can get your own 'modem', but it isn't specific
about an ONT. I use DynDNS, so a static IP isn't really necessary (but
always nice).
On 7/19/23 1:29 PM, system(a)rsx11m.io wrote:
> I don't know that you can bring your own ONT with consumer grade
> internet, at least my understanding has always been that it can't be
> done. I'm not an Optimum customer but I would imagine there is some
> way to disable the routing portion of things and just run an ethernet
> cable from the ONT to your own gear, similar to FIOS. Otherwise, if
> money isn't a huge issue, you might consider a business connection,
> those are generally more lax and you might even get a static IP for
> your troubles.
> On Jul 19, 2023 at 12:47 PM -0400, Thomas DeBellis
> <tommytimesharing(a)gmail.com>, wrote:
>>
>> I'm moving in a few days and am trying to understand what to do about
>> connectivity without drowning (in advertising or whining).
>>
>> I currently have FIOS and had ordered it so that I had a separate
>> Optical Network Terminal (ONT) and router. I plugged my own router
>> into the ONT and the FIOS router into my router and all has been well.
>>
>> The Internet provider at the new location is Optimum Online which
>> previously had been a lot easier to deal with than FIOS as you could
>> just plug into the cable modem or get your own. Naturally, I was
>> provided with a combo ONT/Wireless/Router solution that just isn't
>> going to cut it. I'm trying to search for an ONT, but am getting
>> deluged with the usual stream of noise, junk and advertising. For
>> example, I'm getting Optical-Ethernet converters, which I don't think
>> are what I want.
>>
>> Can anybody point me at a few ONT-only solutions that don't come with
>> all the extra garbage, don't do NAT, Etc.? Or some kind of good
>> introductory information without all the blinking ads?
>>
>> TOMMYT:: [2.520] and VENTI2:: [2.522] will be offline for a few days
>> towards the end of the week.
>>
>>
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
Area 19 is offline while changes are being made to the network. Additionally, the IP address will change. The new IP address for bridge and pyDECnet connections will be bridge.declab.net when it returns.
Thanks!
-Steve Davidson
STRGTE::SYSTEM
SF:iP1
Where are all of these spelled out? I had looked in the Phase IV NSP
functional specification (NSP401.TXT) for them, but only a few seem to
be there.
The background is that I have further enhanced Kermit-20 to use direct
monitor connections when doing remote terminals and also to print the
text of a disconnect. I duly copied over the list in MONSYM, Etc.,
Etc., Etc. Earlier this week, I put some more contingency code into FAL
to handle server crashes. Basically, the controller would sit in a loop
forever restarting crashed server (DAP) forks. Now it waits a while and
stops completely after a certain number of restarts.
While I was at it, I checked its list and found that it was missing text
for disconnect codes 10, 11, 21, 22 and 23. Well, I put it in but got
to wondering what others there might be. Right now Tops-20 Kermit and
DAP know about the following:
*Code*
*Reason Text*
0
Reject or disconnect by object
1
Resource allocation failure
2
Destination node does not exist
3
Remote node shutting down
4
Destination process does not exist
5
Invalid process name field
6
Object is busy
7
Unspecified error
8
Third party abort)
9
User abort (asynchronous disconnect)
/10/
/Invalid node name/
/11/
/Local node shut down/
/21/
/Connect Initiate with illegal destination address/
/22/
/Connect confirm with illegal destination address/
/23/
/Connect initiate or confirm with zero source address/
24
Flow control violation
32
Too many connections to node
33
Too many connections to destination process
34
Access not permitted
35
Logical link services mismatch
36
Invalid account
37
Segment size too small
38
No response from destination process
39
No path to destination node
40
Link aborted due to data loss
41
Destination process does not exist
42
Confirmation of Disconnect Initiate
43
Image data field too long
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.13 of BQTCP/IP.
It's been almost three months since the last official update. Some major
improvements and bugfixes have been done, and it is strongly recommended
that systems are updated.
Highlights:
. Improved TCP performance.
. XLISP updated to V1.7.
. New patch to the TT: driver in order to make telnetd fully vectorized.
Detailed information on things that have been done since the last release:
TCP:
. Added TCP fast retransmit feature.
. Bugfix in TCP. If IO.RAS is used to setup an AST notification, an AST
should immediately be generated if we have received a FIN.
. Improved TCP retransmit timer calculation. It was wrong on socket
creation. Also added handling of delayed transmit time set to 0.
TELNETD:
. Improved internal time handling in telnetd.
. Added full vectorization for TELNETD (if kernel supports it, otherwise
no change from before).
. Added more checks for errors on snd/rcv for telnetd.
RMD:
. Bugfix in RMD. In port page, if xmit or rcv size was greater than
32767, RMD crashed.
NTPD:
. Changed NTPDATE to use time adjustment functionality in kernel, if it
exists.
MAILD:
. Improved MAILD SMTP send error handling.
. Improved mail queue processing to not retry mails extra times just
because an error notification mail is created for something.
. Changed mail daemon to only send notification mails about temporary
delivery problems when the mail have been in the queue for at least 30
minutes.
LISP:
. Updated XLISP to V1.7.
BQTLIB:
. Added lots of documentaiton for BQTLIB. Cleaned up BQTLIB.
. Added functions in BQTLIB for adjusting time.
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.
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 patched TT: driver also makes is possible to get telnetd fully
vectorized, as this version provides two more addresses that are
required by telnetd to access information in the kernel.
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.
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
Greetings all,
I'm performing a firewall replacement along with all kinds of other comms related tasks at my office today.
This means Area 35 will be up and down and possibly out for a few hours.
I'll be starting in the next 2 hours or so. All the work will be finished this afternoon.
Cheers, Wiz!!
Since there has been a bunch of work done to revive what is supposedly a DECnet Phase I implementation (DECnet/8 for RTS/8) I realized I could perhaps get some more information going back that far. Some months ago Nathan Brookwood (formerly known as Nathan Teichholz) gave a talk about the beginning of RSTS-11, and in that he mentioned as an aside that he subsequently served as program manager for the initial development of DECnet.
So I asked him if DECnet/8 sounded familiar and if he could tell me anything further about that time. His reply:
----------
I was responsible for coordinating all the versions of DECnet for the initial "Phase I" releases, but developers in each operating system were responsible for the implementations. Each group was building from the definitions of DDCMP and NSP that were extant in the 1973-75 period. There was also a testing and communications protocol called "NICE" (don't ask me what that stood for) and a file transfer utility.
The Phase I versions did not include routing, and when the developers tried to add routing capabilities to those first versions, they discovered that there was a need to make significant changes to NSP that would preclude backwards compatibility with the Phase I versions. The implementation of DDCMP survived intact, since physical link protocols are below the routing protocols level.
----------
That ties into the statement in the Phase III General Description document which says that Phase I nodes can't coexist with later versions in the same network, and it also matches what the DECnet/8 manual makes quite clear in its chapter discussing the protocol details: Phase I NSP is conceptually pretty similar to Phase II NSP, but the packets are 100% incompatible. So the "significant changes" Nathan mentioned are what happened in DECnet Phase II -- which modifies NSP to include sequence numbers and ACKs and in the process also changes lots of other details in the protocol encoding. That still wasn't quite enough, and Phase III filled in some missing details in an upward compatible fashion (the Connect Ack and Retransmitted Connect Initiate message, as well as timeout and retransmit algorithms).
paul
I've been testing my changes to Tops-20 NFT and ran into what what I
thought were some perhaps interesting results, viz:
NFT>*i twonky*
Attempting connection to TWONKY:: [31.37]
Maximum buffer size: _0!_
Operating System: Tops-10, File System: Tops-10
DAP: 7.0, DECnet: _0.0_
NFT>*i ostara*
Attempting connection to OSTARA:: [31.15]
Maximum buffer size: 4096
Operating System: Ultrix-32, File System: _13 (Unknown)_
DAP: 7.0, DECnet: 1.0
Note that I am clipping the capability display for these examples. By
"interesting", I was surprised to find that Tops-10 is reporting a
buffer size of zero, but more by it reporting a DECnet version of 0.0.Â
Where are these version numbers defined? For Ultrix, I would assume that
I need a more up-to-date list of file systems, given that the highest
that DAP 5.6 states is 9 for OS-8 (!!)
As a comparison, this is what I see for VENTI2:: (Tops-20) and a random
RSTS host.
NFT>*i*
Local Executor is: VENTI2:: [2.522]
Maximum buffer size: 4096
Operating System: Tops-20, File System: Tops-20
DAP: 5.6.1, DECnet: 2.0
NFT>*i pirsts*
Attempting connection to PIRSTS:: [29.205]
Maximum buffer size: 636
Operating System: RSTS/E, File System: RMS-11
DAP: 5.6, DECnet: 4.1
I want to sign on to MIM:: later to see what the RSX NFT client says;
it's certainly possible that I am not displaying this correctly.
I finished the auto-mounting code for Tops-20 DAP, viz:
NFT>*dir venti2::dsk*:<Help>units.hlp*
 VENTI2::TOMMYT:<HELP>
UNITS.HLP.1;P777752Â Â Â Â Â Â Â Â Â Â Â Â Â 1 2210(7)Â Â Â 28-Apr-1980 17:23:03
 VENTI2::TOPS20:<HELP>
UNITS.HLP.1;P777752Â Â Â Â Â Â Â Â Â Â Â Â Â 1 2210(7)Â Â Â 28-Apr-1980 17:23:03
NFT>
Over in FAL, one finds the following debugging output:
[Received Access message (Flg=LEN Cnt=30.)]
[Parsing Access message]
[DSK*: PS:<HELP>UNITS.HLP.1, JFN 7, Unit* High]
[Trying file TOMMYT:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
   .
   .
   .
[Trying file STAR:<Help>units.hlp]
[Failed. No such directory name]
[Mounted file structure TOPS20: on behalf of SLOGIN]
[Trying file TOPS20:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
   .
   .
   .
[Dismounted file structure TOPS20: on behalf of SLOGIN]
Like many things I do, I tend to have an overly optimistic if not naive
idea of the development involved and bump into edge cases. I had to
split DAPLIB up into three separate sources to accommodate the changes,
which kept getting longer as I found another case I hadn't considered.
The same thing happened in spades when I put NRT support into
Kermit-20. The changes were so pervasive that I started looking around
for regression tests. C-Kermit itself has wonderful scripting, which
you can even use to write a compiler. But not testing scripts, so I
wrote my own batch control files.
Anybody know what's available for DECnet; in particular, DAP? I seem to
remember there being something for UETP, but it wasn't extensive.
The RSX image that I created for simh (and thereby also the PiDP-11)
have just been enhanced a bit again.
Since it appears that HECnet is of some interest, I added a section in
the initial boot setup dialog to also configure DECnet-over-IP multinet
links.
So, if anyone wants this, all they need to do is answer a few questions
at initial boot (or whenever they manually run the config script), and
they will have a nicely setup RSX system, which also already connects
using DECnet-over-IP to wherever they want.
This is obviously not limited to HECnet. You can use this to setup links
between any DECnet nodes on any kind of network. HECnet is just one such
instance.
Information on the image can be found at http://mim.stupi.net/pidp.htm
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
After I got done 'enough' with the auto-mounting code for FAL (meaning,
I didn't make the modifications to the access control job because I
bumped into .MSIMF), I turned to fixing a bug that I bumped into a few
years ago. While Tops-20 does not support wildcarding devices, it does
support wildcarding all structures that the system currently has online
via the DSK*: moniker.
So, let's say you're a 60+ who is having those occasional lapses of
memory and you /really/ can't remember a single thing about something
you think you might have somewhere. This is, of course, completely
forgetting that you wanted to find something in the first place... you
can ask the EXEC to do something like, DIRECT DSK*:<*>*SOMETHING*.*.0.Â
You can also hand that to FIND to have it look in all those files.
Some experimentation with NFT shows that Tops-20 FAL supports structure
wildcarding. BUT!! If you're being nosy or are just plain hacking and
do DIRECT DSK*:<*>*.*.*, it crashes with a GLXLIB out of memory error
(ASE, Out of Address Space)...
Researching this shows that Tops-20 DAPLIB tries to buffer messages
before dumping them over the wire and that the decision it makes to dump
is file count based. That appeared to not work properly because of two
issues. First, each file was actually generating four separate
messages: a Name, an Attributes, a Date/Time Attributes and a File
Protection Attributes. Second, the buffer builder was always allocating
a buffer for the maximum size message, 4090 characters (1032 thirty-six
bit words).
That's pretty excessive, considering the typical sizes. Some
instrumentation shows the below:
Message Allocated Actual %Excess
Name 4,090 18 99.56%
Attributes 4,090 17 99.58%
Date/Time 4,090 40 99.02%
Protection 4,090 7 99.83%
I changed the buffering algorithm to dump based on available memory.Â
The starting available memory is 448 pages, so I take ¾ of that to
devote to DAP buffers and ¼ (122 pages) to do the dumping. That fixed
the problem. Then I changed the memory allocation to trim unused words
from the end of messages. That's not working as well as I expected,
probably because I need compact (or 'burp') the memory. Another
alternative would be to build all messages in a single area and then
only allow a chunk in the linked list for what I need. No burping.
A concern is what happens with the Configuration BUFSIZ operator and
what to do if it is 0 (unlimited). The DAP specification specifies that
an operand of zero means that if one of the two systems has anÂ
unlimited buffer size, it sends a 0 and the two systems will use theÂ
nonzero buffer size as the maximum. If both systems send 0, there is no
limit on the length of messages which may be sent.
My question is whether zero is absurd. Does any implementation send that?
It probably doesn't matter that much for sending, but I'm also thinking
that I might hypothetically have a similar problem on receive.Â
Obviously I don't because the current Tops-20 DAP won't negotiate a size
larger than 4096 bytes. Is anything running larger than that? Would it
be silly to?
Hello, newbie here :)
I used to run OpenVMS 7.3 under simh on a Raspberry Pi, but have never learnt past the "newbie" stage about OpenVMS.
With the availability of the x86 Community Edition, I have now 9.2-1 running under Proxmox at home, and thought "maybe it's time to learn about DECnet and join the HECnet".
So here I am, with exactly 0 idea of how DECnet works but the intention to read some of the docs and figure it out enough to join a node or two (or more?)
Regards,
Alice
Much of my DECnet work involves either SIMH or PyDECnet, both of which can do Ethernet over UDP, with a Billquist bridge (or Python equivalent) providing the bridging. So while I've used TAP some years ago, it hasn't been a concern lately.
Then came the time to find an Alpha emulator to run VMS, and it turns out SIMH only has the skeleton of one, not even close to ready for real use. But there are others, and after some searching I landed on AXPbpx. That works well; VMS 8.4 installs on it without problems especially with some help from various Wiki pages. But the obvious complication is that its Ethernet emulation talks to an interface, not UDP (not as far as I can tell). So I looked for TAP as the way to do that since my laptop's physical interface (being WiFi) is not useable for the job.
Surprise: no more Tun/Tap for Mac OS. Or at most, something that's buried in a corner of some other package and at risk of being broken by Apple any day now.
But some Googling for options turned up something very simple that seems to work. Mac OS, in its network settings, lets you define a "virtual interface" bridge. A typical use for that is to share a physical interface, but it doesn't actually need to be connected to a physical interface to work. I tried that.
In System Preferences, Network, at the bottom left is a button bar with + - O, that last one a circle with some dots in it and a downarrow. Click that, last option is Manage virtual interfaces. It lists your bridges, if any. Click on + to add one, give it a name. It will show up in the virtual interfaces list with a Unix-style interface name like "bridge1".
Then you can connect things to that bridge, for example an AXPbox emulated Ethernet, or a PyDECnet circuit via pcap. Wireshark will happily display the packets on that bridged network. And a software bridge can then connect that LAN to other things, for example over UDP.
Enjoy.
paul
Hi Johnny,
The network is up again over here; thanks ... A LOT!
I shelve the formation of the Swbu56 with multinet link to Mim for a while
in favour for more important issues at the moment, but for backup purposes
it is useful to have.
Thanks again,
Reindert
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: Friday, 28 April, 2023 04:20
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] ANKE
After some head scratching, and some RSX hacking, I solved the problem
of accessing the host where ANKE is running. ANKE now restarted, and all
various connections that goes through there should come up now.
Let me know if you spot any problems.
This also means I'd like to reduce the number of links to MIM a little.
Some I like to keep for redundancy, but ANKE is easier to have lots of
different connections set up to.
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
After some head scratching, and some RSX hacking, I solved the problem
of accessing the host where ANKE is running. ANKE now restarted, and all
various connections that goes through there should come up now.
Let me know if you spot any problems.
This also means I'd like to reduce the number of links to MIM a little.
Some I like to keep for redundancy, but ANKE is easier to have lots of
different connections set up to.
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
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.12 of BQTCP/IP.
It's been four months since the last official update. Some major
improvements and bugfixes have been done, and it is strongly recommended
that systems are updated.
Highlights:
. Performance improvements
. Bugfixes
Detailed information on things that have been done since the last release:
Ethernet:
. Tweaked default configuration for ethernet to improve performance.
TCP:
. Implement TCP window scale option.
. Implemented full TCP retransmit timeout computation according to RFC.
Multinet:
. Changed Multinet/TCP to use push for data, and delayed ack.
SPOOF detection:
. Changed call to notify about spammers.
Resolver:
. Bugfix. Resolver library handled IP address string wrong.
IFCONFIG:
. Improved IFCONFIG SHOW ARP to read multiple entries before printing
anything out.
. Added max pool allocation statistics.
TELNETD:
. Fix telnet server to not delay/buffer output if a write with
breakthrough happens.
. Improve telnetd performance by doing more buffering and fewer packets.
. Improved behavior of TELNET and FTP with timeouts and multiple addr.
FTPD:
. Fix FTPD timeout through FTPD$TIMEOUT logical
. Fixed idle timeout handling to FTPD.
. Changed FTPD to use ast notifications for incoming commands, instead
of QIO. That way, no I/O is normally active, and things like task
extensions can proceed without problems.
MAILD:
. Improved MAILD SMTP error handling when happening in the middle of an
ongoing connection.
. Rewritten MAILD queue RMS processing.
. Improved MAILD. Mail content was artificially wrapped because of
buffer length limit. This limit was now raised to proper value.
. Improved MAILD SMTP send connection error handling.
. Changed MAILD MAIL11 reception to do delivery in separate process.
. Fixed MAILD SMTP$RELAY handling.
. Added capability to act as relay for mail for other systems.
. Bugfixes in mail handling and error reporting.
. Added ability to handle multiple IP addresses for host in MAILD
NTPD:
. Added improved exit status to NTPD to indicate if time changed.
TELNET:
. Added ability to handle multiple IP addresses for host in TELNET
. Improved behavior of TELNET with timeouts and multiple addr.
FTP:
. Added better error message to FTP in case of timeout.
. Added PORT command to FTP client.
. Improved FTP HELP command. Improved FTP help file.
. Added ability to handle multiple IP addresses for host in FTP
. Improved behavior of FTP with timeouts and multiple addr.
MAILRD:
. Improved MAILRD command line parsing.
. Changed MAIL DIRECTORY listing format slightly.
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.
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.
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
The DAP 5.6 specification (28-Mar-1980) does not appear to have much
information concerning device mounting.
It's not clear how much DAP was designed to be concerned with such
activities, but it would appear that it implicitly expects that any
device that is available is usable. There are some bits in the File
Access Options (FOP) and Generic Device Characteristics (DEV) attributes
that have some information concerning mounting, viz:
*Attribute*
*Bit*
*Name*
*Meaning*
FOP
13
FB$DMO
Rewind and dismount magnetic tape on close.
DEV
10
FB$MNT
Device is currently mounted.
DEV
11
FB$DMT
Deviceis marked for dismount.
So assuming you are accessing a magnetic tape, you can request that it
be rewound and dismounted when closed and you can get some information
concerning mount status.
At this time of DAP design, large systems basically lived on tape and
disk mounts, given the expense of the devices to actually read and write
their respective media. There was a cost for a mount, but if you were
using a lot of space, it could pay to have your own media where you
wouldn't get hit with the storage costs.
Mounting structures is also a well understood mechanism to provide
additional access control granularity.
A "regulated" structure on Tops-20 can not be used unless it is first
mounted by the user. It may be spun up and online, but if it is
regulated, you must mount it first. This gives you the opportunity to
put policy on the mount with an access control request. At Columbia,
nobody was allowed to mount the (regulated) staff structure (CU:, an
RP07) unless they were staff. Students were not allowed to mount
anything. Paying customers could mount non-domestic regulated
structures. I wrote the code for the 'Judge', our access control job
(or ACJ) which did this as it required some hooks in Galaxy (Quasar and
MOUNTR).
FAL is not subject to such ACJ policy because it specifically informs
Tops-20 to by-pass mount counts. So that's kind of a back door because
you could use FAL to snoop around regulated structures, which is exactly
what we didn't want to be happening. It bothered me, but not enough for
me to tell management that it should be addressed.
I was fixing a bug in FAL ANONYMOUS processing when I recalled this and
it began to bother me more. I don't want regulated structures being
implicitly used. My extended mode FTP server does not bypass mount
counts and this is what keeps web crawlers from snooping through every
file I have. You have to explicitly know the structure name and request
it with an SMNT verb which you can then put policy on. So I scratched
the itch and implemented a MOUNTING command with the following options:
* BYPASSED, the current FAL behavior: use whatever is online.
* PREVENTED, respect regulated structure mount counts and fail if the
structure isn't mounted.
* AUTOMATIC, attempt to mount the structure on the behalf of the user
where necessary.
PREVENTED is the most restricted, as a FAL job only has access to
unregulated structures (which require no mounting). So that's good.
AUTOMATIC maybe gets you the best of both worlds. You can access online
structures provided policy allows you to, elsewhere which means that
users that expect to be able to mount structures will have this done for
them. I have yet to put in another command to restrict ANONYMOUS usage,
in other words, forbid automatic mounting for ANONYMOUS.
Is my reading of DAP is close enough? How do other DEC operating
systems handle this? I know VMS can handle disk and tape mounts, I
forget about RSTS, RSX and RT.
Correct disk images of layered products (y2k patched) are uploaded to https://pdp-11.online/~form/files/pdp-11/rt-11/layered/
- MU MASIC-11/RT-11 V2.00R
- BASIC-11/RT-11 V02-03S
- FORTRAN IV/RT-11 V2.8
- FORTRAN-77 V5.0A
On 19/04/2023 18:33, Dave McGuire wrote:
>
> Oh, weird, ok. Please let me know what you find. Thanks!
>
> -Dave
>
> On 4/18/23 13:40, Oleg Safiullin wrote:
>> Hmm.
>> It looks like this directory contains wrong/broken images and patches, so I'll look at my archive and put correct images there.
>>
>> On 18/04/2023 17:46, Dave McGuire wrote:
>>>
>>> Ahh, excellent, thank you Oleg!
>>>
>>> -Dave
>>>
>>> On 4/18/23 02:04, Oleg Safiullin wrote:
>>>> You can get some layered products for RT-11 here: https://pdp-11.online/~form/files/pdp-11/rt-11/layered/
>>>> There're BASIC-11, BASIC-PLUS, FORTRAN IV, FORTRAN 77, MU/BASIC-11 and pre-built PASCAL there.
>>>> All of these are Y2K-patched. MU/BASIC-11 also patched to make it work under RT-11 V5.7
>>>>
>>>>
>>>> On 18/04/2023 05:02, Dave McGuire wrote:
>>>>>
>>>>> Has anyone found a release of FORTRAN-IV for RT-11 that's later than v2.5?
>>>>>
>>>>> Thanks,
>>>>> -Dave
>>>>>
>>>>
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>
>
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 || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Now that I'm done with Kermit-20, I wanted to get back to finishing up
some other work that I had been doing. FAL, DAP and NFT are in good
enough shape for me to leave them alone for the moment, so that's
another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR (SMTP
over DECnet). Fixing this required modifying DDT, which I had to do to
fix another issue I had introduced into Kermit. I wanted to have a
quick look at what Tops-20 hosts might be up on HECnet and wrote up a
little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It builds
a connection the NCU's of various nodes to determine the path that a
message might take to get there. Think of it like traceroute or ping -R
(RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / NI-0-0 <= TOMMYT (2.520) 1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
There is now an OpenVMS/x86 system on HECnet, as I would expect/hope, DECnet Phase IV seems to be working just fine. It’s routing through my VAX/VMS 5.5-2 system.
Zane
Version 5.3 is the first major release of Kermit-20 in two decades and
represents over a year of development for the following functionality:**
·Updates Kermit to version 7 of Tops-20.**
·Adds DECnet NRT transport to Tops-10, Tops-20 and Ultrix hosts.**
·Adds pseudo-terminal support.**
·Support for batch stream execution, including extensive testing.**
·Microsecond timing (limited by Tops-20)**
·Efficiency Enhancements**
·Symbolic (C) escape sequences and enhanced parsing**
·New and Enhanced commands**
·Revamped and enhanced macro facility**
I am still working out where this is going up on the Internet, but for
now, HECnet users can feel free to access the package anonymously as
follows:
VENTI2::K20: Kermit-20 Executable and release notes
VENTI2::K20D: Kermit documentation in various formats
VENTI2::K20S: Macro source code plus build files for Batch (.CTL)
and Interactive (.MIC)
VENTI2::K20T: Extensive testing control files and results
*Gigantic* thanks to Bob Armstrong for providing /countless/ Tops-10
cycles, support and other resources to me for testing and troubleshooting.
I'm celebrating climbing out of this particular rabbit hole by breaking
Tops-20 NFT, but FAL is OK. I think.
