Guys. I figure I should try to get a more formalized handling of
connections to HECnet.
With my bridge, it's mostly just people connecting to me, but this is
not a solution that scales very well, so in general I now try to
discourage people from this option. When possible, I prefer to move
people away from it.
Multinet on the other hand scales well. And is possible to use directly
both in VMS and RSX. However, it is silly and inefficient if all
multinet links are to go to me. So I'm thinking about identifying a few
people/places elsewhere in the world, which can be used for connections
where it makes more sense for a somewhat closer point of connection.
So, I would go on dealing with Europe. Might at some point be that we'd
like a second point in the south of Europe, but that is not a high
priority right now.
However, for the US, it would be nice if we could identify a location on
each coast, which have a capable system, and normally is always online,
and which have a good bandwidth, and would be willing to setup
connections to new machines that want to come online.
So, are there any takers? I'll continue to be the first point of contact
when people come asking, but I'd be happy if I could redirect them to
the appropriate person once we have figured out a few basic details.
And then these two persons can work on establishing the actual link.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at 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 release contains a lot of fixes and improvements in many areas.
There are a couple of very serious bugs in TCP that is fixed in this
release which is why I really encourage people to upgrade. (They do not
happen often, but if they happen, they have a high chance of crashing
the system.)
Highlights:
- Stability and reliability improvements in TCP.
- Improved logic for TCP probing, keepalive and retransmits.
Magica (a real PDP-11/70) and Mim (an emulated PDP-11/74) have been
serving traffic for several weeks without any issues, and I think I have
finally found and fixed a very obscure problem that occasionally could
crash the system. (And both of these machines are more or less fully
exposed to the internet, so they see a *lot* of connections and random
attempts to compromise them all the time.)
Detailed information on things that have been done since the last release:
TCP:
- Correct TCP reception. It could stop the retransmit timer even if
there was still data outstanding under some circumstances.
- Bugfix in data resend in TCP. Under some circumstances the retransmit
timer stopped even though there was data to send.
- Improved TCP retransmit timers to better handle probing and keepalive.
- Improved TCP keepalive timer handling.
- Improved TCP timeout handling for closing sockets.
- Improved TCP retransmit timer restart logic in received TCP ACK
processing.
- General rework of TCP retransmit logic.
- Bugfix. In TCP TimeWait state, received FIN packets did not result in
an RST packet.
- Changed TCP FinwWait2 to use keepalive timer to probe connections.
- Improvement to TCP reception to dedup received packets also for
packets that are pending.
- Bugfix in TCP packet sending. If we ran out of IP POOL, memory got
corrupted.
- Improved handling of TCP receive window if TCP receive size is shrunk.
- Add probing of socket during closing stages, since we have no other
way to tell if the remote end is still around.
- Change how TCP decides if it should probe a connection.
- Bugfix in TCP. If a socket had no window but outstanding data, and was
closed, and other end never opened up a window (for example if the
remote end is gone), then the socket would get stuck in Fin-Wait-1.
- Changed TC driver so that user ASTs are generated immediately if there
is data to be read and the AST address is changed.
- Improve TCP options processing. Some badly formatted tcp options
packets could crash the system.
- Improved TCP handling of ICMP error packets.
UDP:
- Bugfix in UDP. If several error packets were received for a socket,
several ASTs were queued, but only one error is saved, meaning the
additional ASTs could make code try to read several times, when all
except the first would not have anything to actually read.
TELNET/TELNETD:
- Improved abort handling in telnet client.
- Changed TELNETD do do spoof notifications in a simpler way.
- Rewritten TELNETD to handle fast input without loosing characters.
- Fix mapping error under special circumstances in telnetd, which could
corrupt the system.
- Added more IAC options processing in telnet and telnetd.
DNS:
- Improved name resolution handling if no UDP available.
- Improve resolver domain I/O error handling.
RWHOD:
- Added handling of no UDP available in RWHOD.
MAILD:
- Improve MAILD handling of DECnet connections.
- Improved privilege handling in MAILD.
- Improved maild unread message function.
- Added manual holding of mails.
General:
- Improved ability to stop protocols from IFCONFIG.
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
The firewall for Mim have now been removed, so no need for the alternate
ports, but Mim is still listening to the alternate ports as well.
ftp: 10021
telnet: 10023
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Excuse the noise, but I?ve got a fragmented recollection of a strange unit of time, and my faulty memory seems to equate this with VAX and/or VMS. My google-fu has failed me (or confirmed that this is some sort of fake memory) however I thought I?d run it past the experts in here.
Does anyone know of anything strange about the unit of time, or possibly the epoch, or something else associated with time measurement (or the TOY clock or basically anything to do with time) in the DEC world? Sorry for the vagueness of the question, but hopefully someone can help :)
Ian
I'm not sure that asymmetric is the correct description but I can't think of
a better term. I am using SIMH and I have a two node cluster (with a quorum
disk) the two nodes have a common system disk.
The two nodes are RODNEL (1.1) booting from SYS0 and ADV2 (1.3) booting from
SYS2. Both are running DECnet Plus both are running Multinet for the IP
stack. At one time there was also a node (never actually a member of the
cluster called HCBVAX (1.2) it booted from SYS1 but it no longer exists.
The nodes are connected over an Ethernet and the MAC addresses are the ones
that I would expect AA-00-04-00-01-04 (1.1) and AA-00-04-00-03-04 (1.3)
HCBVAX was AA-00-04-00-02-04 (1.2)
I can login to RODNEL and "set host adv2" with no problem, I can login to
ADV2 and "set host rondel" with no problem. On each of the nodes I can "show
cluster" and I see what I expect to see with no errors. While logged in to
RODNEL the command "moni cluster" works fine. While logged in to ADV2 the
wheels seem to fall off the bus - "show cluster" is fine but "moni cluster"
isn't Any help would be appreciated. This is the information that I have
gathered so far (I am not happy with the forwarding address in the error
message from "moni proc" on ADV2 which seems to arise from RODNEL
--Dave
View of Cluster from system ID 1027 node: ADV2 22-APR-2018
22:24:50
+-----------------------------+
| SYSTEMS | MEMBERS |
+-------------------+---------|
| NODE | SOFTWARE | STATUS |
+--------+----------+---------|
| ADV2 | VMS V7.3 | MEMBER |
| RODNEL | VMS V7.3 | MEMBER |
+-----------------------------+
^Z
$
$ moni cluster
%MONITOR-I-ESTABCON, establishing connection to remote node(s)...
%%%%%%%%%%% OPCOM 22-APR-2018 22:24:56.75 %%%%%%%%%%%
Message from user SYSTEM on RODNEL
Event: Address Unreachable PDU Discard from: Node LOCAL:.RODNEL Routing,
at: 2018-04-22-23:24:56.740-04:00Iinf
Discard Reason=Destination Addrs Unknown,
Source Address=49::00-01:AA-00-04-00-03-04:21,
Forwarding Address=49::00-01:AA-00-04-00-02-04:21
eventUid FC95D640-467B-11E8-99E1-AA0004000104
entityUid 5683CC80-467B-11E8-8004-AA0004000104
streamUid 5A113900-467B-11E8-8004-AA0004000104
Still on ADV2 - NCP is odd as well:
$ mcr ncp
NCP>sho exec char
Node Volatile Characteristics as of 22-APR-2018 22:31:17
Executor node = 1.3 (ADV2)
Identification = DECnet-OSI for OpenVMS
Management version = V4.0.0
Incoming timer = 0
Outgoing timer = 0
NSP version = V4.1.0
Maximum links = 0
Delay factor = 0
Delay weight = 0
Inactivity timer = 0
Retransmit factor = 0
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 0
Subaddresses = 0
Broadcast routing timer = 0
Maximum address = 0
Maximum circuits = 0
Maximum cost = 0
Maximum hops = 0
Maximum visits = 0
Maximum area = 0
Max broadcast nonrouters = 0
Max broadcast routers = 0
Maximum path splits = 0
Area maximum cost = 0
Area maximum hops = 0
Maximum buffers = 0
Segment buffer size = 0
Buffer size = 0
Pipeline quota = 0
Alias maximum links = 0
Path split policy = Normal
Maximum Declared Objects = 0
NCP>show know nodes
Known Node Volatile Summary as of 22-APR-2018 22:31:29
Executor node = 1.3 (ADV2)
State = on
Identification = DECnet-OSI for OpenVMS
NCP>def node rodnel
Node address (1.1-63.1023): 1.1
Node name (1-6 characters): rodnel
NCP>set node rodnel all
%NCP-W-UNRCMP, Unrecognized component
NCP>set node rodnel
Node address (1.1-63.1023): 1.1
Node name (1-6 characters): rodnel
%NCP-W-UNRCMP, Unrecognized component , Node
NCP>exit
Whereas RODNEL seems happier:
NCP>sho exec char
Node Volatile Characteristics as of 22-APR-2018 20:15:29
Executor node = 1.1 (RODNEL)
Identification = DECnet-OSI for OpenVMS
Management version = V4.0.0
Incoming timer = 0
Outgoing timer = 0
NSP version = V4.1.0
Maximum links = 0
Delay factor = 0
Delay weight = 0
Inactivity timer = 0
Retransmit factor = 0
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 0
Subaddresses = 0
Broadcast routing timer = 0
Maximum address = 0
Maximum circuits = 0
Maximum cost = 0
Maximum hops = 0
Maximum visits = 0
Maximum area = 0
Max broadcast nonrouters = 0
Max broadcast routers = 0
Maximum path splits = 0
Area maximum cost = 0
Area maximum hops = 0
Maximum buffers = 0
Segment buffer size = 0
Buffer size = 0
Pipeline quota = 0
Alias maximum links = 0
Path split policy = Normal
Maximum Declared Objects = 0
NCP>sho kno node
Known Node Volatile Summary as of 22-APR-2018 20:15:37
Executor node = 1.1 (RODNEL)
State = on
Identification = DECnet-OSI for OpenVMS
Node State Active Delay Circuit Next node
Links
1.3 (ADV2) 1.1 (RODNEL)
NCP>sho node adv2 char
Node Volatile Characteristics as of 22-APR-2018 20:16:02
Remote node = 1.3 (ADV2)
Service password = 0000000000000000
Have anyone heard from Steve Davidson recently, or know of a working
address for him?
Trying to reestablish a connection.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hey Johnny, is the DECUS RSX library up on MIM:: somewhere?
Or does anyone else have it up and accessible via hecnet?
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
