I finally got my issues with Comcast straightened out and I now have static IP addresses. They are
IPv4: 50.185.8.122
IPv6: 2603:300b:6c4:21a0:c77b:4f58:27e4:6de2
These are also always available in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>
Hopefully, this will be the last change for a while.
Mark Berryman
Area 27
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.14 of BQTCP/IP.
It's been almost six months since the last official update. Some major
improvements and bugfixes have been done, and it is strongly recommended
that systems are updated.
Highlights:
Bugfixes for potentially serious bugs in all drivers.
New, completely rewritten name resolver.
New, completely rewritten RWHOD daemon, and added related user applications.
Added functionality in UDP and TCP drivers.
Detailed information on things that have been done since the last release:
IP:
. Bugfixes in all drivers. Sometimes task header was not mapped when
doing manipulations that assumed the task header was mapped.
UDP:
. Bugfixes in all drivers. Sometimes task header was not mapped when
doing manipulations that assumed the task header was mapped.
. Bugfix in UDP. If UDP gets an ICMP error packet, system crash out, as
it was incorrectly interpreted as a packet with data.
. Add EFN user notification in UDP.
TCP:
. Bugfixes in all drivers. Sometimes task header was not mapped when
doing manipulations that assumed the task header was mapped.
. Add user flag for blocking ASTs in TCP.
. Improve TCP ack, window update and retransmit performance.
. Improve TCP retransmit timer in case we are probing a zero window.
. Improve retransmit handling. Fixed keepalive management including
actually activating it when enabled.
. Remove separate probe handling.
. Bugfix. If a TCP socket initially cannot send, the retry logic might
not ever have sent any data.
. Bugfix. The fast retransmit logic in TCP was not working right.
RESOLVER:
. Improve resolver ACP abort handling to avoid a race condition.
. Improved DNS resolver. Remember all DNS servers we query, and mark
servers bad not only if we get errors, but also if we get no responses
at all.
. Improved DNS resolver. Remember if we have a bad DNS server, and don't
make use of it for a little while. Fix various timing issues in DNS
resolver.
. Improved DNS resolver. If we get NXDOMAIN on a query, and we also
might consider doing an mDNS query for it, we should not fail the query
at the first NXDOMAIN error. Improve staggered DNS query progress.
. Improved DNS resolver. It now can make use of TASK defined logical names.
. Bugfix in DNS handling of CNAMEs.
. Improved DNS resolving. Proper processing of .local domain.
. Added DNS lookup tool.
. Complete new resolver ACP written.
TELNETD:
. Change telnet server to use flag to block ASTs when terminal driver
indicates XOFF, so that we can still be notified for things like
connection closed.
. Fixed TELNET server to properly handle if TC: is not running.
TELNET:
. Bugfix in telnet client. Even if server responded with DONT to
terminal type, the terminal type was sent.
. Bugfix in telnet client. If we are in binary mode, CR should not be
padded.
RWHOD:
. Added new RWHOD daemon, along with RUPTIME and RWHO client.
MAIL:
. Bugfix in mail reader. If a mail didn't have a label on it, the mail
reader could get into an infinite loop. Repair function did not repair
such mails.
. EXPUNGE function in mail was very slow.
. Bugfix. MAILRD could crash when showing mails with long lines.
LPR:
. Changed LPQ program to be able to take hostname argument.
C libraries:
. Bugfix in C IP libraries. Memory corruption could happen because a
register could get corrupted.
. Bugfix in IPC library. neterr was not set on a successful rcv.
BP2 libraries:
. Revised the BP2 inet library.
IPGEN:
. Bugfix in IPGEN.CMD. On initial generation, if manual interface
configuration is selected, the program crashed out.
IPINS:
. Improved IPINS to dynamically select QNA or UNA for ethernet.
IPCONFIG:
. Rewritten IPCONFIG.CMD
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are somewhat critical, but will also 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
Ok, this is a long shot, but does anybody know the algorithm used by the
VMS (and presumably RSX) RX01/RX02 driver for interleaving sectors?
More specifically, logical blocks on VMS are always 512 bytes but RX01
sectors are 128 bytes and RX02 sectors are 256. So each logical block
consists of 4 RX01 sectors or 2 RX02 sectors. I'm presuming these sectors
are not contiguous, but rather the device driver uses some kind of
interleave to minimize the rotational delays. What exactly is that
algorithm?
Or even more detail, I have a bunch of RX01 and RX02 image files (as VMS
disk files) that were created using a program that dumps consecutive VMS
logical blocks (using SYS$QIOW(.IO$_READLBLK,.). This works great for
things where the logical to physical translation is hidden from the OS (like
all MSCP drives) for RX drives that's not the case. I need to figure out
how to unscramble the 512 byte blocks in my VMS file to re-create the
original sectors.
And no, I don't have access to the actual diskettes to dump them again.
Shouldn't matter - the data is in the file, I just have to figure out the
correct bit shuffling to get it back in the right order. I guess if I get
really desperate I'll try to find the source listings for the drivers, but
I'm hoping somebody just knows.
Bob
Hi,
I've been running the Panda distribution of TOPS-20 on the KLH10 simulator on a Raspberry Pi 4 for some years now. It's WALACH on HECnet. The version of the Pi's OS had been the 32 bit implementation but as some of these were being replaced by 8Gb versions, I recently took the plunge and updated (by re-imaging) everything to the current 64 bit Raspberry Pi OS.
In rebuilding SIMH and KLH10, I sync'd with the latest sources. With SIMH, there were no issues but the KLH10 updates, seemingly post ~2021 have broken networking. The line in my klt20.ini file is:
devdef ni0 564 ni20 dedic=true ifc=tapX ifmeth=tap+bridge ipaddr=192.168.2.46 enaddr=aa:00:04:00:6c:74
With the dpni20 executable running as root, the 'old' behaviour causes it to use the default bridge name 'bridge0' and create a tap device 'tap0' (it disregards the ifc=tapX part of the line).
The new behaviour results in a whole load of IOCTL errors while attempting to create the tap device.
I avoided the problem by restoring the original version of the KLH10 simulator sources and compiling.
The whole thing has reminded me that I wanted to fix the code a while back so that it would make use of an existing tap device, created via /etc/network/interfaces, with full control granted to the non-privileged user the rest of KLH10 runs under, then dpni20 would not need to be privileged. Once I've finished with the upgrades I might have a go.... along with all of the other half-done/half-forgotten projects in this area.
Keith
Hi,
During my postgraduate days, I ran ANU NEWS on our VAX/VMS systems and we peered large parts of the hierarchy. I think even back then we were exclusively NNTP over TCP/IP. I have a vague memory that I wrote a multi-threaded NNTP server for ANU but it was using the CMUTEK TCP/IP product so it was all done with QIO and ASTs - none of this weird select stuff of Unix sockets.
With Google groups being hit by 1000s of spam messages a day - astrology, voodoo, death spells, etc. - I'm tempted to get ANU NEWS installed and running again, probably SIMH-hosted VAX OpenVMS and, as above, peer some of the groups. Disc space and bandwidth aren't an issue and I'd like to see NNTP running over DECnet.... And I'm more familiar with ANU NEWS's SMG interface than I ever was with the likes of tin and rm.
Actually, wanting to do this has less to do with Google's mess and more about nostalgia. If/when it's all up and running, I'll consider getting it running on some real Alpha or IA64 hardware, probably based mostly on which has the lower power consumption.
Just wondering if anybody else is doing/done something similar.
Keith
Version 5.3(235)-5 incorporates all fixes since the major release of
5.3, Edit 230 in January of this year. These are as follows and can be
identified in the code with the edit number as the prefix of a comment.
<about:blank?compose#_Toc137380940>
[231] Fix RECEIVE with no file name
[232] 36 bit byte file sizes
[233] Transaction Log and Debug log fixes and enhancements
Transaction logging
Garbled Text
Write-Protection Failures
Enhancements
Debug Log Decode Fix
[234] Error messages may not be seen if displayed in remote server
[235] Properly signal and handle file errors in server mode
Additional Batch Tests
K2036P: Kermit-20 36 Bit Mode via pseudo-terminal
K2036C: Kermit-20 36 Bit Mode via pseudo-terminal with parity
Updated Help
All source, documentation, executables, control files and test data are
available for Anonymous NFT on HECnet from VENTI2::PS:<OINKY.K20MIT> and
associated subdirectories. Documentation includes more detail on the
above list. All regression tests have passed except for Tops-10 because
of some local networking issues.
Be aware that VENTI2:: is running a FAL alpha candidate, so let me know
if you get unexpected behavior.
Hi,
Is anyone testing this mailing list's recipients?
The reason I ask is:
06-02 00:07:58 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:07:59 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:34:26 NOREC SMTP OKBL DE 65.108.62.138:40994 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:45:56 NOREC SMTP OKBL DE 65.108.62.138:41946 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:57:11 NOREC SMTP OKBL DE 65.108.62.138:43082 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
Activity from cassini.dfupdate.se is valid and expected.
The other attempt(s) from static.216.112.243.136.clients.your-server.de was an attempted non-local relay to jessindewinter(a)gmail.com<mailto:jessindewinter@gmail.com>
It wasn't exactly a problem and the attempt was denied with some tar-pitting along the way.
Times in GMT+01:00 (BST) by the way.
Keith
Hey folks. Does anyone have images of the RSX-11M v4.8 RK06/RK07
kit? I have the RL kit, but I would like to have the RK06/RK07 kit.
I think Oleg may have it, but my mail server doesn't seem to be
talking to his mail server.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hey folks, would anyone here happen to have the firmware files for
the Emulex Performance 2500 and Performance 4000 LAT terminal servers?
I really regret not having snagged a copy of that stuff when I
managed a bunch of those in the early 1990s. Wasn't thinking ahead I guess.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
