3 Mar
2020
3 Mar
'20
6:54 p.m.
I had a shower thought that I'd like to run down in order to better understand how
DECnet routing works. Ok, I wasn't actually in the shower.
Let's say that my local DECnet is successfully hooked in to HECnet. For the sake of
discussion, imagine I'm using PyDECnet to connect to my upstream node, and I don't
have my own area number. That means that my PyDECnet node would be a level 1 router,
right?
Now, imagine that I inadvertently bring up a system on my local ethernet with an
uncoordinated DECnet node ID. Perhaps I booted some random RL02 pack in my VAX without
remembering to unplug the ethernet cable, or booted a random disk image in SIMH with it
connected to the TAP device. Just to make things exciting, let's say that the system
comes up with a node ID that properly exists elsewhere in HECnet.
If the node ID happens to be in the same area that I'm properly in, does the adjacency
detection find it and break things? What if it comes up with a node ID in a different
area? Just how much trouble would this cause?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
3 Mar
3 Mar
7:13 p.m.
You may be talking about a number of things here.? DECnet node numbers
are something (very) vaguely like IP tuples, except with half the bits
and fixed fields.? The upper 6 bits constitute the area, the lower 10
bits constitute the number within area.? This is what I recall:
1. If the node number's name is not defined to other systems, then many
user level programs will not be able to see if. Tops-20 won't able
to build a connection.
* Phase II DECnet used node names directly, I think.
2. If the number is the same as another system in different area, then
everything is fine except for 1.
3. If the number is the same as another system in the _same_ area, then
somebody will become 'unhappy'.
* I don't remember how the adjacency is reported for point-to-point.
4. If you think of MAC address clash on the same Ethernet segment as
opposed to different segments, you may appreciate a similarity.
5. I don't remember the finer details of the differences between a
level 1 and 2 router.
* A level 1 router handles routing through point-to-point in the
same area.
* If a different area is requested, then the level 1 router hands
the packet to a level 2 router.
First, if the node number
On 3/3/20 12:54 PM, Mark J. Blair wrote:
I had a shower thought that I'd like to run down
in order to better understand how DECnet routing works. Ok, I wasn't actually in the
shower.
Let's say that my local DECnet is successfully hooked in to HECnet. For the sake of
discussion, imagine I'm using PyDECnet to connect to my upstream node, and I don't
have my own area number. That means that my PyDECnet node would be a level 1 router,
right?
Now, imagine that I inadvertently bring up a system on my local ethernet with an
uncoordinated DECnet node ID. Perhaps I booted some random RL02 pack in my VAX without
remembering to unplug the ethernet cable, or booted a random disk image in SIMH with it
connected to the TAP device. Just to make things exciting, let's say that the system
comes up with a node ID that properly exists elsewhere in HECnet.
If the node ID happens to be in the same area that I'm properly in, does the
adjacency detection find it and break things? What if it comes up with a node ID in a
different area? Just how much trouble would this cause?
8:16 p.m.
On Mar 3, 2020, at 1:13 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
You may be talking about a number of things here. DECnet node numbers are something
(very) vaguely like IP tuples, except with half the bits and fixed fields. The upper 6
bits constitute the area, the lower 10 bits constitute the number within area. This is
what I recall:
? If the node number's name is not defined to other systems, then many user level
programs will not be able to see if. Tops-20 won't able to build a connection.
Interesting. It depends on the application API. For example, in RSTS the "node
name" argument can contain a number in string form, which lets you connect by
address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
? Phase II DECnet used node names directly, I think.
Yes, though it also mentions node addresses. The spec requires a value between 2 and 240,
with no explanation why. The address appears in the Node Init message, but nowhere else
that I can see.
? If the number is the same as another system in
different area, then everything is fine except for 1.
That isn't a duplicate address. The address is a 16 bit value, not a 6 or 10 bit
value. If some of the bits are the same but others aren't, you have two different
addresses.
? If the number is the same as another system in the
same area, then somebody will become 'unhappy'.
? I don't remember how the adjacency is reported for point-to-point.
? If you think of MAC address clash on the same Ethernet segment as opposed to different
segments, you may appreciate a similarity.
Two nodes on the same Ethernet (not just segment but bridged also) will result in a
duplicate Ethernet address. DECnet doesn't define anything that checks for this.
Depending on the implementation, you might see it as an "adjacency" to your own
node address on a circuit. The same issue appears if you have a router with multiple
Ethernet interfaces and you attach those to the same Ethernet. Phase V of course fixes
this by not using a MAC address derived from the node address. So does Phase IV Prime,
but implementations of that are rare at best.
If the multiple nodes are connected to point to point links, or to disjoint Ethernets,
then as far as DECnet is concerned that's just one node reachable via several paths.
That ability is of course intentional -- a router can be reached on any of its interfaces.
A duplicate address essentially looks like a partitioned node. Other nodes would see one
or the other of the two, depending on which is closer (by path cost).
? I don't remember the finer details of the
differences between a level 1 and 2 router.
If one of the duplicate-address nodes is a level 2 router but the other isn't, then
the one that is will show in entry 0 of the routing tables as a possible "nearest L2
router". That will work just fine.
If both are level 2 routers, then for the out of area routing they just act as redundant
L2 routers offering out of area service. The usual rule that an area must not be
partitioned applies, of course.
That brings up a particularly nasty case. Suppose you have an L2 router that duplicates
someone else's address, and in fact it isn't connected into the area its address
says it belongs in. The scenario of "I accidentally booted up an old node"
could do this. If the rogue node isn't connected to other L2 nodes, that's benign
because its L2 services will be turned off -- an L2 router only offers out of area service
if it has out of area circuits that are up. But if the rogue happens to be connected to
some other L2 router, then it would claim connectivity to its area in its L2 routing
messages. That would make the entire area (except the rogue node itself) effectively
unreachable to anyone who has a lower cost L2 path to the rogue than to the real area.
paul
9:13 p.m.
I have had someone on area 31 bring up a node that conflicts with my MACOS9 node running
Pathworks for Macintosh. The Mac handles it by turning it's executor off and throwing
a error popup saying "someone grabbed my address".
Since I am not sitting there staring at the Mac screen all the time, the situation always
has gone away by the time I get to investigating why MACOS9 dropped off.
This makes me wonder if whoever has that other node gets a similar message and
disconnects. But that still leaves MACOS9 in limbo.
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
On Mar 3, 2020, at 2:16 PM, Paul Koning <paulkoning
at comcast.net> wrote:
On Mar 3, 2020, at 1:13 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
You may be talking about a number of things here. DECnet node numbers are something
(very) vaguely like IP tuples, except with half the bits and fixed fields. The upper 6
bits constitute the area, the lower 10 bits constitute the number within area. This is
what I recall:
? If the node number's name is not defined to other systems, then many user level
programs will not be able to see if. Tops-20 won't able to build a connection.
Interesting. It depends on the application API. For example, in RSTS the "node
name" argument can contain a number in string form, which lets you connect by
address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
? Phase II DECnet used node names
directly, I think.
Yes, though it also mentions node addresses. The spec requires a value between 2 and
240, with no explanation why. The address appears in the Node Init message, but nowhere
else that I can see.
? If the number is the same as another system
in different area, then everything is fine except for 1.
That isn't a duplicate address. The address is a 16 bit value, not a 6 or 10 bit
value. If some of the bits are the same but others aren't, you have two different
addresses.
? If the number is the same as another system
in the same area, then somebody will become 'unhappy'.
? I don't remember how the adjacency is reported for point-to-point.
? If you think of MAC address clash on the same Ethernet segment as opposed to
different segments, you may appreciate a similarity.
Two nodes on the same Ethernet (not just segment but bridged also) will result in a
duplicate Ethernet address. DECnet doesn't define anything that checks for this.
Depending on the implementation, you might see it as an "adjacency" to your own
node address on a circuit. The same issue appears if you have a router with multiple
Ethernet interfaces and you attach those to the same Ethernet. Phase V of course fixes
this by not using a MAC address derived from the node address. So does Phase IV Prime,
but implementations of that are rare at best.
If the multiple nodes are connected to point to point links, or to disjoint Ethernets,
then as far as DECnet is concerned that's just one node reachable via several paths.
That ability is of course intentional -- a router can be reached on any of its interfaces.
A duplicate address essentially looks like a partitioned node. Other nodes would see one
or the other of the two, depending on which is closer (by path cost).
? I don't remember the finer details of
the differences between a level 1 and 2 router.
If one of the duplicate-address nodes is a level 2 router but the other isn't, then
the one that is will show in entry 0 of the routing tables as a possible "nearest L2
router". That will work just fine.
If both are level 2 routers, then for the out of area routing they just act as redundant
L2 routers offering out of area service. The usual rule that an area must not be
partitioned applies, of course.
That brings up a particularly nasty case. Suppose you have an L2 router that duplicates
someone else's address, and in fact it isn't connected into the area its address
says it belongs in. The scenario of "I accidentally booted up an old node"
could do this. If the rogue node isn't connected to other L2 nodes, that's benign
because its L2 services will be turned off -- an L2 router only offers out of area service
if it has out of area circuits that are up. But if the rogue happens to be connected to
some other L2 router, then it would claim connectivity to its area in its L2 routing
messages. That would make the entire area (except the rogue node itself) effectively
unreachable to anyone who has a lower cost L2 path to the rogue than to the real area.
paul
9:33 p.m.
Thinking more ... it is difficult to run Wireshark 24/7 trying to trap the rogue
node's source. But PYDNET - a DECnet/python rev 486 node - does L1 routing for area
31. Wouldn't PYDNET know that the address for MACOS9 is taken and that node is up, and
therefore another node with the same address trying to come up is likely a situation to be
at the least logged ? Knowing Paul, it probably already does, it has not struck me to look
at PYDNET logs before.
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
On Mar 3, 2020, at 3:13 PM, Supratim Sanyal
<supratim at riseup.net> wrote:
I have had someone on area 31 bring up a node that conflicts with my MACOS9 node running
Pathworks for Macintosh. The Mac handles it by turning it's executor off and throwing
a error popup saying "someone grabbed my address".
Since I am not sitting there staring at the Mac screen all the time, the situation always
has gone away by the time I get to investigating why MACOS9 dropped off.
This makes me wonder if whoever has that other node gets a similar message and
disconnects. But that still leaves MACOS9 in limbo.
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
> On Mar 3, 2020, at 2:16 PM, Paul Koning <paulkoning at comcast.net> wrote:
>
>
>
>> On Mar 3, 2020, at 1:13 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>>
>> You may be talking about a number of things here. DECnet node numbers are
something (very) vaguely like IP tuples, except with half the bits and fixed fields. The
upper 6 bits constitute the area, the lower 10 bits constitute the number within area.
This is what I recall:
>>
>> ? If the node number's name is not defined to other systems, then many
user level programs will not be able to see if. Tops-20 won't able to build a
connection.
>
> Interesting. It depends on the application API. For example, in RSTS the "node
name" argument can contain a number in string form, which lets you connect by
address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
>
>> ? Phase II DECnet used node names directly, I think.
>
> Yes, though it also mentions node addresses. The spec requires a value between 2 and
240, with no explanation why. The address appears in the Node Init message, but nowhere
else that I can see.
>
>> ? If the number is the same as another system in different area, then
everything is fine except for 1.
>
> That isn't a duplicate address. The address is a 16 bit value, not a 6 or 10 bit
value. If some of the bits are the same but others aren't, you have two different
addresses.
>
>> ? If the number is the same as another system in the same area, then somebody
will become 'unhappy'.
>> ? I don't remember how the adjacency is reported for point-to-point.
>> ? If you think of MAC address clash on the same Ethernet segment as opposed to
different segments, you may appreciate a similarity.
>
> Two nodes on the same Ethernet (not just segment but bridged also) will result in a
duplicate Ethernet address. DECnet doesn't define anything that checks for this.
Depending on the implementation, you might see it as an "adjacency" to your own
node address on a circuit. The same issue appears if you have a router with multiple
Ethernet interfaces and you attach those to the same Ethernet. Phase V of course fixes
this by not using a MAC address derived from the node address. So does Phase IV Prime,
but implementations of that are rare at best.
>
> If the multiple nodes are connected to point to point links, or to disjoint
Ethernets, then as far as DECnet is concerned that's just one node reachable via
several paths. That ability is of course intentional -- a router can be reached on any of
its interfaces. A duplicate address essentially looks like a partitioned node. Other
nodes would see one or the other of the two, depending on which is closer (by path cost).
>
>> ? I don't remember the finer details of the differences between a level 1
and 2 router.
>
> If one of the duplicate-address nodes is a level 2 router but the other isn't,
then the one that is will show in entry 0 of the routing tables as a possible
"nearest L2 router". That will work just fine.
>
> If both are level 2 routers, then for the out of area routing they just act as
redundant L2 routers offering out of area service. The usual rule that an area must not
be partitioned applies, of course.
>
> That brings up a particularly nasty case. Suppose you have an L2 router that
duplicates someone else's address, and in fact it isn't connected into the area
its address says it belongs in. The scenario of "I accidentally booted up an old
node" could do this. If the rogue node isn't connected to other L2 nodes,
that's benign because its L2 services will be turned off -- an L2 router only offers
out of area service if it has out of area circuits that are up. But if the rogue happens
to be connected to some other L2 router, then it would claim connectivity to its area in
its L2 routing messages. That would make the entire area (except the rogue node itself)
effectively unreachable to anyone who has a lower cost L2 path to the rogue than to the
real area.
>
> paul
>
10:45 p.m.
As I mentioned, seeing the same address on two circuits is perfectly normal and expected
if that node is a router.
For an endnode, it would be possible to create some hacks that would help. They
aren't in PyDECnet because that implements, just about exactly, the letter of the DNA
specs, and no such checks are in those specs.
If a given router were to see the same address as a neighbor ("adjacency") on
multiple circuits, and the hello messages indicate it's an endnode, then that would be
an error.
But the picture isn't so clear if an endnode appears as an adjacency while that
address is also shown as reachable (but not adjacent, i.e., hop count > 1) in the
routing tables. The reason is the "counting up" behavior of Phase III/IV
routing that is characteristic of "distance vector" algorithms. When a node
goes down and its adjacency times out, that node is still known as reachable by others in
the area. The former neighbor now thinks the downed node is 3 hops away. It reports that
change, which causes other routers to revise their distance, and the process counts up by
one or two hops at a time until you hit "max hops" and the node is now declared
unreachable. If you have events enabled, you can see this clearly: an adjacency down
results in a node unreachable, but the unreachable event is delayed by 10-20 seconds -- or
longer, possibly significantly longer, if there are lots of routers. Keep in mind that
routers only send updates at most once a second, to prevent floods of change messages.
That reduces overhead but also puts a time bound on how fast a router can know a node has
gone away.
The result: if I see an endnode come up, it might be that it was recently up, either on
this node or elsewhere, and it hasn't counted up to unreachable yet. Given the
protocol rules this is unavoidable.
It would be possible to have a configuration setting that holds off acting on a new
adjacency until the count-up process has had a chance to work. If after a suitable delay
the address still appears reachable, that would be an error. This means, of course, that
a node whose circuit bounced will be unavailable for a while longer.
Phase V avoids this issue entirely by using link state routing, essentially a map
algorithm, so there you can see duplicate addresses directly.
I'm puzzled by the bit about MacOS PATHworks detecting duplicate address. How would
it do that? As an end node, it doesn't see routing messages at all. It could see a
duplicate address on its own Ethernet, by detecting the receipt of a message from its
Ethernet address that it didn't send. But I can see no way it could know about an
off-LAN duplicate.
paul
On Mar 3, 2020, at 3:33 PM, Supratim Sanyal
<supratim at riseup.net> wrote:
Thinking more ... it is difficult to run Wireshark 24/7 trying to trap the rogue
node's source. But PYDNET - a DECnet/python rev 486 node - does L1 routing for area
31. Wouldn't PYDNET know that the address for MACOS9 is taken and that node is up, and
therefore another node with the same address trying to come up is likely a situation to be
at the least logged ? Knowing Paul, it probably already does, it has not struck me to look
at PYDNET logs before.
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet <http://www.update.uu.se/~bqt/hecnet.html>
On Mar 3, 2020, at 3:13 PM, Supratim Sanyal <supratim at riseup.net
<mailto:supratim at riseup.net>> wrote:
> I have had someone on area 31 bring up a node that conflicts with my MACOS9 node
running Pathworks for Macintosh. The Mac handles it by turning it's executor off and
throwing a error popup saying "someone grabbed my address".
>
> Since I am not sitting there staring at the Mac screen all the time, the situation
always has gone away by the time I get to investigating why MACOS9 dropped off.
>
> This makes me wonder if whoever has that other node gets a similar message and
disconnects. But that still leaves MACOS9 in limbo.
>
>
> ---
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet <http://www.update.uu.se/~bqt/hecnet.html>
>
>
> On Mar 3, 2020, at 2:16 PM, Paul Koning <paulkoning at comcast.net
<mailto:paulkoning at comcast.net>> wrote:
>
>>
>>
>>> On Mar 3, 2020, at 1:13 PM, Thomas DeBellis <tommytimesharing at gmail.com
<mailto:tommytimesharing at gmail.com>> wrote:
>>>
>>> You may be talking about a number of things here. DECnet node numbers are
something (very) vaguely like IP tuples, except with half the bits and fixed fields. The
upper 6 bits constitute the area, the lower 10 bits constitute the number within area.
This is what I recall:
>>>
>>> ? If the node number's name is not defined to other systems, then many
user level programs will not be able to see if. Tops-20 won't able to build a
connection.
>>
>> Interesting. It depends on the application API. For example, in RSTS the
"node name" argument can contain a number in string form, which lets you connect
by address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
>>
>>> ? Phase II DECnet used node names directly, I think.
>>
>> Yes, though it also mentions node addresses. The spec requires a value between 2
and 240, with no explanation why. The address appears in the Node Init message, but
nowhere else that I can see.
>>
>>> ? If the number is the same as another system in different area, then
everything is fine except for 1.
>>
>> That isn't a duplicate address. The address is a 16 bit value, not a 6 or 10
bit value. If some of the bits are the same but others aren't, you have two different
addresses.
>>
>>> ? If the number is the same as another system in the same area, then
somebody will become 'unhappy'.
>>> ? I don't remember how the adjacency is reported for
point-to-point.
>>> ? If you think of MAC address clash on the same Ethernet segment as
opposed to different segments, you may appreciate a similarity.
>>
>> Two nodes on the same Ethernet (not just segment but bridged also) will result in
a duplicate Ethernet address. DECnet doesn't define anything that checks for this.
Depending on the implementation, you might see it as an "adjacency" to your own
node address on a circuit. The same issue appears if you have a router with multiple
Ethernet interfaces and you attach those to the same Ethernet. Phase V of course fixes
this by not using a MAC address derived from the node address. So does Phase IV Prime,
but implementations of that are rare at best.
>>
>> If the multiple nodes are connected to point to point links, or to disjoint
Ethernets, then as far as DECnet is concerned that's just one node reachable via
several paths. That ability is of course intentional -- a router can be reached on any of
its interfaces. A duplicate address essentially looks like a partitioned node. Other
nodes would see one or the other of the two, depending on which is closer (by path cost).
>>
>>> ? I don't remember the finer details of the differences between a
level 1 and 2 router.
>>
>> If one of the duplicate-address nodes is a level 2 router but the other
isn't, then the one that is will show in entry 0 of the routing tables as a possible
"nearest L2 router". That will work just fine.
>>
>> If both are level 2 routers, then for the out of area routing they just act as
redundant L2 routers offering out of area service. The usual rule that an area must not
be partitioned applies, of course.
>>
>> That brings up a particularly nasty case. Suppose you have an L2 router that
duplicates someone else's address, and in fact it isn't connected into the area
its address says it belongs in. The scenario of "I accidentally booted up an old
node" could do this. If the rogue node isn't connected to other L2 nodes,
that's benign because its L2 services will be turned off -- an L2 router only offers
out of area service if it has out of area circuits that are up. But if the rogue happens
to be connected to some other L2 router, then it would claim connectivity to its area in
its L2 routing messages. That would make the entire area (except the rogue node itself)
effectively unreachable to anyone who has a lower cost L2 path to the rogue than to the
real area.
>>
>> paul
>>
10:55 p.m.
On 3/3/20 4:45 PM, Paul Koning wrote:
I'm puzzled by the bit about MacOS PATHworks
detecting duplicate
address. ?How would it do that? ?As an end node, it doesn't see
routing messages at all. ?It could see a duplicate address on its own
Ethernet, by detecting the receipt of a message from its Ethernet
address that it didn't send. ?But I can see no way it could know about
an off-LAN duplicate.
My bad. MACOS9 sits in a little Ethernet network with other nodes, the
Ethernet extended virtually over VDE2. PYDNET then does not really do
anything much in this case, nor is it going be able to do much.
The good thing is I now realize the "rogue" node must be on the same
Ethernet segment. Which narrows the possibilities down.
Thanks.
paul
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
On Mar 3, 2020, at 3:33 PM, Supratim Sanyal
<supratim at riseup.net
<mailto:supratim at riseup.net>> wrote:
Thinking more ... it is difficult to run Wireshark 24/7 trying to
trap the rogue node's source. But PYDNET - a DECnet/python rev 486
node - does L1 routing for area 31. Wouldn't PYDNET know that the
address for MACOS9 is taken and that node is up, and therefore
another node with the same address trying to come up is likely a
situation to be at the least logged ? Knowing Paul, it probably
already does, it has not struck me to look at PYDNET logs before.
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet <http://www.update.uu.se/~bqt/hecnet.html>
On Mar 3, 2020, at 3:13 PM, Supratim Sanyal <supratim at riseup.net
<mailto:supratim at riseup.net>> wrote:
> I have had someone on area 31 bring up a node that conflicts with my
> MACOS9 node running Pathworks for Macintosh. The Mac handles it by
> turning it's executor off and throwing a error popup saying "someone
> grabbed my address".
>
> Since I am not sitting there staring at the Mac screen all the time,
> the situation always has gone away by the time I get to
> investigating why MACOS9 dropped off.
>
> This makes me wonder if whoever has that other node gets a similar
> message and disconnects. But that still leaves MACOS9 in limbo.
>
>
> ---
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet <http://www.update.uu.se/~bqt/hecnet.html>
>
>
> On Mar 3, 2020, at 2:16 PM, Paul Koning <paulkoning at comcast.net
> <mailto:paulkoning at comcast.net>> wrote:
>
>>
>>
>>> On Mar 3, 2020, at 1:13 PM, Thomas DeBellis
>>> <tommytimesharing at gmail.com <mailto:tommytimesharing at
gmail.com>>
>>> wrote:
>>>
>>> You may be talking about a number of things here. ?DECnet node
>>> numbers are something (very) vaguely like IP tuples, except with
>>> half the bits and fixed fields. ?The upper 6 bits constitute the
>>> area, the lower 10 bits constitute the number within area. ?This
>>> is what I recall:
>>>
>>> ? ?? If the node number's name is not defined to other systems,
>>> then many user level programs will not be able to see if. ?Tops-20
>>> won't able to build a connection.
>>
>> Interesting. ?It depends on the application API. ?For example, in
>> RSTS the "node name" argument can contain a number in string form,
>> which lets you connect by address. ?But in some places in NCP
>> things don't work if there isn't a name for the node. ?I would call
>> that a bug.
>>
>>> ? ? ? ?? Phase II DECnet used node names directly, I think.
>>
>> Yes, though it also mentions node addresses. ?The spec requires a
>> value between 2 and 240, with no explanation why. ?The address
>> appears in the Node Init message, but nowhere else that I can see.
>>
>>> ? ?? If the number is the same as another system in different
>>> area, then everything is fine except for 1.
>>
>> That isn't a duplicate address. ?The address is a 16 bit value, not
>> a 6 or 10 bit value. ?If some of the bits are the same but others
>> aren't, you have two different addresses.
>>
>>> ? ?? If the number is the same as another system in the same area,
>>> then somebody will become 'unhappy'.
>>> ? ? ? ?? I don't remember how the adjacency is reported for
>>> point-to-point.
>>> ? ?? If you think of MAC address clash on the same Ethernet
>>> segment as opposed to different segments, you may appreciate a
>>> similarity.
>>
>> Two nodes on the same Ethernet (not just segment but bridged also)
>> will result in a duplicate Ethernet address. ?DECnet doesn't define
>> anything that checks for this. ?Depending on the implementation,
>> you might see it as an "adjacency" to your own node address on a
>> circuit. ?The same issue appears if you have a router with multiple
>> Ethernet interfaces and you attach those to the same Ethernet.
>> ?Phase V of course fixes this by not using a MAC address derived
>> from the node address. ?So does Phase IV Prime, but implementations
>> of that are rare at best.
>>
>> If the multiple nodes are connected to point to point links, or to
>> disjoint Ethernets, then as far as DECnet is concerned that's just
>> one node reachable via several paths. ?That ability is of course
>> intentional -- a router can be reached on any of its interfaces. ?A
>> duplicate address essentially looks like a partitioned node. ?Other
>> nodes would see one or the other of the two, depending on which is
>> closer (by path cost).
>>
>>> ? ?? I don't remember the finer details of the differences between
>>> a level 1 and 2 router.
>>
>> If one of the duplicate-address nodes is a level 2 router but the
>> other isn't, then the one that is will show in entry 0 of the
>> routing tables as a possible "nearest L2 router". ?That will work
>> just fine.
>>
>> If both are level 2 routers, then for the out of area routing they
>> just act as redundant L2 routers offering out of area service. ?The
>> usual rule that an area must not be partitioned applies, of course.
>>
>> That brings up a particularly nasty case. ?Suppose you have an L2
>> router that duplicates someone else's address, and in fact it isn't
>> connected into the area its address says it belongs in. ?The
>> scenario of "I accidentally booted up an old node" could do this.
>> ?If the rogue node isn't connected to other L2 nodes, that's benign
>> because its L2 services will be turned off -- an L2 router only
>> offers out of area service if it has out of area circuits that are
>> up. ?But if the rogue happens to be connected to some other L2
>> router, then it would claim connectivity to its area in its L2
>> routing messages. ?That would make the entire area (except the
>> rogue node itself) effectively unreachable to anyone who has a
>> lower cost L2 path to the rogue than to the real area.
>>
>> ? ?paul
>>
4 Mar
4 Mar
12:57 a.m.
You've put your finger on something that's puzzled me for quite some
time about Tops-20's lexical implementation.
There is no standardized syntax in the generalized parsing interface
(COMND% and GTJFN%) for using numeric node names. If you ask COMND% to
parse a node name and do not shut off standard syntax, then you must
specify a maximum six character word which conforms to the SIXBIT
character set followed a double colon, which looks like what you would
think it would, viz: VENTI2::
However, the integration into the monitor isn't as seamless as it
appears to be under VMS.? In order to make a connection, you must build
a special string for GTJFN% to swallow.? Let's suppose I wanted to grab
the latest node list from MIM:: (which I do on a weekly basis); you
would type MIM::FIX.T20;0 as the source to NFT. That's not what GTJFN%
wants and you must transmogrify the string into DCN:MIM-FAL. Once that
connection is open, you negotiate DAP and then ask MIM:: to send the file.
There is no standardized "[a.b.c.d]" syntax such as what you might use
to get to an IP4 host which is neither in the DNS nor host tables.? You
can use COMND% to parse for a number optionally followed by a dot and
another number and the operator NICE interface (NCP) does in fact do
this.? Indeed, it is the only interface besides SETNOD which does this
(in order to define nodes).? So I can give an area.address to NCP as an
argument to a TELL verb in order to get remote information.
Neither programs will work right for the general user.? The user could
use COMND% to parse for the numbers and then use the .NDRNM function of
the NODE% JSYS to convert them into a name which is palatable to GTJFN%.
However?and this is the point?if that name isn't in Tops-20's node data
base, then the NODE% JSYS will fail and you have nothing to give to
GTJFN%. Therefore there is no way for a general user to make a connection.
I can't make up my mind as to whether this is a bug, a misfeature or
unfinished business.? Tops-20 installations had millions of (1980's)
dollars hardware and software, trained staffs and often large
populations.? Management of them was very different from a lab machine
(PDP-8, PDP-11) or departmental machine (VAX 11/780). At least in the
university setting, students are an inquisitive lot and a lot of had to
be done to prevent certain kinds of activities, probing and downright
meddling.? It seems to me that not defining the node in the first place
on an academic machine is a great misfeature as it eliminates probing.
However, as I've said before (viz., the NFT: device and FTS), there are
parts of Tops-20 DECnet that strike me as not fully productized.? One
example is that there is no way for /anybody/ to extract the area and
number of a node once it is the monitor.? You can (and should) verify
that the node is 'legitimate' by using .NDVFY function of the NODE%
JSYS, which will also tell you some interesting things about it.?
However, it will not divulge the aforementioned numbers.? It annoyed me
enough so that I modified the monitor to do just that with an additional
function, .NDVFX and I use this in DAP (but don't depend on it) and in
the mailer (where I do).
I haven't posted the changes anywhere because I can't make up my mind
whether this was fixing an oversight or breaking a design decision or
indeed, whether that should even matter.
Another example is that, once a node is inserted into the monitor data
base, there is *no* documented way to remove it.? As I was implementing
.NDVFX, I was looking at the in-area hashing code and noticed that it
appears that the monitor will remove a node marked as -1 (36 bits).? I
have yet to test this.? Certainly SETNOD gives no hint (another reason
I'm toying with a rewrite).
Curiouser and curiouser.? Do the above two functionalities exist in
other operating systems?
------------------------------------------------------------------------
On 3/3/20 2:16 PM, Paul Koning wrote:
Interesting. It depends on the application API. For example, in RSTS the "node
name" argument can contain a number in string form, which lets you connect by
address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
> ------------------------------------------------------------------------
> On Mar 3, 2020, at 1:13 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> You may be talking about a number of things here. DECnet node numbers are something
(very) vaguely like IP tuples, except with half the bits and fixed fields. The upper 6
bits constitute the area, the lower 10 bits constitute the number within area. This is
what I recall:
>
> ? If the node number's name is not defined to other systems, then many user
level programs will not be able to see if. Tops-20 won't able to build a connection.
2:34 a.m.
On Mar 3, 2020, at 6:57 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
You've put your finger on something that's puzzled me for quite some time about
Tops-20's lexical implementation.
There is no standardized syntax in the generalized parsing interface (COMND% and GTJFN%)
for using numeric node names. If you ask COMND% to parse a node name and do not shut off
standard syntax, then you must specify a maximum six character word which conforms to the
SIXBIT character set followed a double colon, which looks like what you would think it
would, viz: VENTI2::
However, the integration into the monitor isn't as seamless as it appears to be under
VMS. In order to make a connection, you must build a special string for GTJFN% to
swallow. Let's suppose I wanted to grab the latest node list from MIM:: (which I do
on a weekly basis); you would type MIM::FIX.T20;0 as the source to NFT. That's not
what GTJFN% wants and you must transmogrify the string into DCN:MIM-FAL. Once that
connection is open, you negotiate DAP and then ask MIM:: to send the file.
There is no standardized "[a.b.c.d]" syntax such as what you might use to get
to an IP4 host which is neither in the DNS nor host tables. You can use COMND% to parse
for a number optionally followed by a dot and another number and the operator NICE
interface (NCP) does in fact do this. Indeed, it is the only interface besides SETNOD
which does this (in order to define nodes). So I can give an area.address to NCP as an
argument to a TELL verb in order to get remote information.
...
Curiouser and curiouser. Do the above two functionalities exist in other operating
systems?
The area.node notation, and the Phase 3 numeric address notation, were intended to be
standard, not just limited to NCP. And indeed DECnet/E (in RSTS) does both:
$ dir 1.13::[decnet]nodenames.dat;0
Node: 1.13
User: guest
Password:
System Password:
Directory 1.13::DU1:[DECNET]
Name .Typ Size Prot Access Date Time UIC
NODENAMES.DAT;254 30/30 < 40> 28-Feb-20 28-Feb-20 01:08 [7,14]
Total of 30/30 blocks in 1 file.
$ dir 1037::[decnet]nodenames.dat;0
Node: 1037
User: guest
Password:
System Password:
Directory 1037::DU1:[DECNET]
Name .Typ Size Prot Access Date Time UIC
NODENAMES.DAT;254 30/30 < 40> 28-Feb-20 28-Feb-20 01:08 [7,14]
Total of 30/30 blocks in 1 file.
These are DECnet kernel features. The connect call takes a 6-character ASCII node
argument, and if that's numeric string (possibly with a . in it) it's interpreted
as a node number in the way shown. Of course, 63.1023 doesn't fit in 6 characters so
for that one you'd be forced to write it as 65535.
paul
4:38 a.m.
The area.node notation, and the Phase 3 numeric address
notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
5:38 a.m.
I took Bob's note as an invitation to perform a little experiment on
ZITI::.? It looks like my suspicions were confirmed; if the node name
isn't in Tops-20's hash table, then you are not going there, no way, no how.
* I verified that ZITI:: was in my area, online and that I could do a
SHOW EXECUTOR,
* I then undefined poor ZITI::, noticing that it subsequently was
reported as offline (clearly a vicious calumny).
* The NICE process (NCP) could no longer communicate with it either by
name /or by number/.
* When I redefined ZITI:: with SETNOD, SHOW EXECUTOR started working
again.
I wonder why they never allowed real area.number connections in
Tops-20?? I mean other than they were running away from the product...?
Hum...
!i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
!opr
OPR>enter ncp
NCP>telL ziti:: shoW exeCUTOR
NCP>
23:20:29 ??? NCP
??? ??? Request # 5 Accepted
NCP>
23:20:30 ??? NCP
Request # 5; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>push
?PANDA TOPS-20 Command processor 7.1(4454)-5
?End of TOMMYT:<SLOGIN>COMAND.CMD.12
@enable
!setnod
SETNOD>set nODE -1 . -1 nAME ZITI
SETNOD>insert
SETNOD>exi
!i dec
?Local DECNET node: VENTI2.? Nodes reachable: 5.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT??? VENTI2
!pop
NCP>telL ziti:: shoW exeCUTOR
NCP>
23:22:13 ??? NCP
??? ??? Request # 6 Accepted
23:22:13 ??? NCP
Request # 6; Show Executor Node Summary Failed, Listener link connect
failed,
Link Failure = Node unreachable
NCP>telL 2.16 shoW exECUTOR
NCP>
23:22:23 ??? NCP
??? ??? Request # 7 Accepted
23:22:23 ??? NCP
Request # 7; Show Executor Node Summary Failed, Invalid identification,
Node address has no matching node name
NCP>
23:22:28 ??? ? -- DECnet link message --
Communication failure to the following nodes:
ZITI
NCP>push
!c setnod
SETNOD>set nod 2.16 name ziti
SETNOD>insert
SETNOD>exi
!i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
!pop
NCP>tel ziti:: shoW exeCUTOR
NCP>
23:23:35 ??? NCP
??? ??? Request # 8 Accepted
NCP>
23:23:36 ??? NCP
Request # 8; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>exit
------------------------------------------------------------------------
On 3/3/20 10:38 PM, Robert Armstrong wrote:
The area.node
notation, and the Phase 3 numeric address notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::,
2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
10:06 a.m.
Bob,
Actually, HECnet does have a node 63.1023 in my lab. It is a hidden area node for testing
purposes. :-)
-Steve Davidson
SF:iP1
On Mar 3, 2020, at 22:38, Robert Armstrong <bob at
jfcl.com> wrote:
?
The area.node notation, and the Phase 3 numeric address notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
8:59 p.m.
On Mar 3, 2020, at 10:38 PM, Robert Armstrong <bob
at jfcl.com> wrote:
Here?s a few more:
DECnet-RSX
Kernel interface requires a node name (up to 6 characters) so can only connect to nodes
which are in the system database.
Access control uses the syntax nodename/user/password/account::
DECnet-Ultrix (and the probably never released DECnet-SCO)
Kernel interface take a 16-bit binary node address. Applications typically use the
dnetconn() library routine which accepts all three node
address formats node::, 2.16:: and 2064::.
Like RSX, access control uses the syntax nodename/user/password/account::
DECnet-Linux
Similar kernel interface to DECnet-Ultrix.
The original code used VMS syntax for access control but that meant that you would either
have to escape each quote character or use an
extra pair of quotes, so either
?nodename?user password??:: or
nodename/user/password::
While working at DEC I had a PRO-350 in my office with a nodename of 4cast:: intended to
help shake out the nodename vs. node address
distinction.
John.
The area.node notation, and the Phase 3 numeric
address notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
5 Mar
5 Mar
2:09 p.m.
On 2020-03-04 20:59, John Forecast wrote:
I think access control allows either nodename/user/password/account:: or
nodename"user password":: everywhere.
However, only NCP allows numeric addresses. Anything else needs the
nodename. But within NCP you can play using node numbers everywhere just
fine.
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
On Mar 3, 2020, at 10:38 PM, Robert Armstrong
<bob at jfcl.com> wrote:
Here?s a few more:
DECnet-RSX
Kernel interface requires a node name (up to 6 characters) so can only connect to nodes
which are in the system database.
Access control uses the syntax nodename/user/password/account:: The area.node notation, and the Phase 3 numeric
address notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
4:31 p.m.
I never heard of DECnet on SCO, but we ran Ultrix on the first (8650)
and second (8700) VAX's which we got at the data center for
instructional use.? My last use of SCO in the early 2000's timeframe
struck me as a product that was behind the times.? It still didn't have
some features that Ultrix had; Linux and Digital Unix (1990's Alpha) had
far passed it by.
As I recall, Ultrix would accept node"user password account"::, the
account being necessary because the 20's ran real accounting.? I don't
remember the functionality being used much.? Since we got burned with
the cancellation of the 2080, we were not inclined to get locked into
Digital anything, so no LAT anything.? For terminals, we had an
alternate hardware solution (Gandalf PACX) which was more flexible in
some ways that could also connect to our IBM mainframes.? For files, the
vastly additional functionality of DAP was never leveraged; we stuck
with FTP.? We discouraged node"user password account":: as this would
allow shoulder surfing.? We may have modified some of the Ultrix source
to refuse this nomenclature.
Shortly after we got an 8700, we got our first SPARC and essentially
exited any Digital solution afterwards.? DEC tried very hard to keep the
account; we got a large number of micro-vaxes, Pro-350's and the like.?
I had a micro-vax (running Ultrix) for about 8 months before I left and
I thought it quite a reasonable little box.? The Pro-350's weren't
really appreciated, this perhaps mostly due to the strange keyboard
which didn't have common keys where they have been for decades.? In
retrospect, I wonder about that as the keyboard wasn't any stranger than
an IBM 3270, which I also used to tweak the HASP (PDP-11) code on the VM
side.
I also used that functionality with our IBM system programmer staff
troubleshoot IBMSPL when it got cranky, which happened a lot in early
releases.? That surprised me as I had known one of the authors (K. Reti)
at Marlboro and he had always struck me as pretty brilliant.? But I was
young and impressionable.
I'm not sure what happened with CCnet after the Columbia data center got
out of the Digital.? We had at least one VAX 11/780 on campus
(Chemistry), but I don't know what they did.? Digital had better luck
with Stevens; for a time, every undergraduate was _required_ to buy a
350 in order to be able to do homework and graduate.
What's strange is what has lasted.? To this day, you can sign on to IBM
mainframe and the only terminal that is supported is a 3270, half
duplex.? They all speak IP6 and HTTPS and everything else, but if you
are going to write a program under TSO...
On 3/5/20 8:09 AM, Johnny Billquist wrote:
On 2020-03-04 20:59, John Forecast wrote:
I think access control allows either nodename/user/password/account:: or
nodename"user password":: everywhere.
However, only NCP allows numeric addresses. Anything else needs the
nodename. But within NCP you can play using node numbers everywhere
just fine.
? Johnny
On Mar 3, 2020, at 10:38 PM, Robert Armstrong
<bob at jfcl.com> wrote:
Here?s a few more:
DECnet-RSX
????Kernel interface requires a node name (up to 6 characters) so can
only connect to nodes which are in the system database.
????Access control uses the syntax nodename/user/password/account:: The area.node notation, and the Phase 3 numeric
address notation, were
intended to be standard, not just limited to NCP.? And indeed DECnet/E
(in RSTS) does both:
? FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::.? It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e.
Phase IV)
implementations.? Are there systems that don't?
? And the VMS parser doesn't limit the node name to 6 characters, so
you can
say "63.1023::" (although HECnet has no such node).
Bob
6:26 p.m.
On Mar 5, 2020, at 10:31 AM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
I never heard of DECnet on SCO, but we ran Ultrix on the first (8650) and second (8700)
VAX's which we got at the data center for instructional use. My last use of SCO in
the early 2000's timeframe struck me as a product that was behind the times. It still
didn't have some features that Ultrix had; Linux and Digital Unix (1990's Alpha)
had far passed it by.
In the late ?80s DEC had the PATHWORKS product for networking with PCs. The first
version ran on VMS and a subsequent version ran on Ultrix. Sometime around 88/89 they
wanted to build a cheaper, lower end product by porting the Ultrix version to run on a
386/486 running SCO Unix and requested a DECnet implementation. A major problem during the
implementation was that Ultrix was BSD based and used sockets while SCO Unix was System V
based and used TLI (Transport Layer Interface). We ended up with a user-mode mapping layer
but that required intercepting at least fork(), exec() and the initial startup logic so
that we could encapsulate the open socket information in environment variables and rebuild
the necessary data structures in the forked or new image. Ugly, but it worked OK in this
limited environment. After sending the last message, I found a SPD describing the various
PATHWORKS products, including SCO so it probably did ship to some customers.
As I recall, Ultrix would accept node"user
password account"::, the account being necessary because the 20's ran real
accounting. I don't remember the functionality being used much. Since we got burned
with the cancellation of the 2080, we were not inclined to get locked into Digital
anything, so no LAT anything. For terminals, we had an alternate hardware solution
(Gandalf PACX) which was more flexible in some ways that could also connect to our IBM
mainframes. For files, the vastly additional functionality of DAP was never leveraged; we
stuck with FTP. We discouraged node"user password account":: as this would
allow shoulder surfing. We may have modified some of the Ultrix source to refuse this
nomenclature.
I just tried using this syntax with Ultrix 2.2 and Ultrix 4.0 and neither accepted
that format.
Shortly after we got an 8700, we got our first SPARC
and essentially exited any Digital solution afterwards. DEC tried very hard to keep the
account; we got a large number of micro-vaxes, Pro-350's and the like. I had a
micro-vax (running Ultrix) for about 8 months before I left and I thought it quite a
reasonable little box. The Pro-350's weren't really appreciated, this perhaps
mostly due to the strange keyboard which didn't have common keys where they have been
for decades. In retrospect, I wonder about that as the keyboard wasn't any stranger
than an IBM 3270, which I also used to tweak the HASP (PDP-11) code on the VM side.
I also used that functionality with our IBM system programmer staff troubleshoot IBMSPL
when it got cranky, which happened a lot in early releases. That surprised me as I had
known one of the authors (K. Reti) at Marlboro and he had always struck me as pretty
brilliant. But I was young and impressionable.
I'm not sure what happened with CCnet after the Columbia data center got out of the
Digital. We had at least one VAX 11/780 on campus (Chemistry), but I don't know what
they did. Digital had better luck with Stevens; for a time, every undergraduate was
required to buy a 350 in order to be able to do homework and graduate.
What's strange is what has lasted. To this day, you can sign on to IBM mainframe and
the only terminal that is supported is a 3270, half duplex. They all speak IP6 and HTTPS
and everything else, but if you are going to write a program under TSO...
On 3/5/20 8:09 AM, Johnny Billquist wrote:
> On 2020-03-04 20:59, John Forecast wrote:
>>
>>> On Mar 3, 2020, at 10:38 PM, Robert Armstrong <bob at jfcl.com>
<mailto:bob at jfcl.com> wrote:
>>>
>>>> The area.node notation, and the Phase 3 numeric address notation, were
>>>> intended to be standard, not just limited to NCP. And indeed DECnet/E
>>>> (in RSTS) does both:
>>>
>>> FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
>>> 2064::. It also accepts the node"name password":: notation as
well.
>>> Actually I thought this was a standard thing in all "modern" (i.e.
Phase IV)
>>> implementations. Are there systems that don't?
>>>
>>> And the VMS parser doesn't limit the node name to 6 characters, so you
can
>>> say "63.1023::" (although HECnet has no such node).
>>>
>>> Bob
>>>
>>
>> Here?s a few more:
>>
>> DECnet-RSX
>>
>> Kernel interface requires a node name (up to 6 characters) so can only
connect to nodes which are in the system database.
>> Access control uses the syntax nodename/user/password/account::
>
> I think access control allows either nodename/user/password/account:: or
> nodename"user password":: everywhere.
>
> However, only NCP allows numeric addresses. Anything else needs the nodename. But
within NCP you can play using node numbers everywhere just fine.
>
> Johnny
>
7:38 p.m.
That's interesting; I thought I recognized the format.? I wonder where
in the world I could be remembering it from?? It is surely not parsed by
either COMND% or GTJFN% and I don't believe Tops-20 NFT currently allows
it.? However, I haven't really gotten into tinkering with NFT, yet.? I'm
finishing up some changes to FAL and DAP and then I'm probably going to
work with Johnny a bit to iron out some oddities in the email interface
(SMTP DECnet and Tops-20 MAIL11).
I keep thinking about implementing rename in Tops-20 DAP, but I just
stumbled over what appears to be a BLISS based implementation of FAL and
DAP which MRC never seems to have put up.? Maybe it's great.
So what era does Ultrix 2.2 hail from?? I believe we had an early
version, something like 1986 or 1987.? However, I doubt they put that
syntax in and then took it out.? So do I understand that DECnet wouldn't
have been available on Ultrix 1.x?? I can't remember what version we
had, which is remarkable because I wrote the entire Id system for it
(using Ingress).
We appreciated some aspects of Ultrix; as I recall, it had both System V
and BSD functionality.? I used the System V semaphore interface to
implement locking for the Id system.? That much I remember; wrapping the
calls in routines called P(); and V(); (obviously).? Regretfully, this
is the only Dutch I ever learned...
I thought Ultrix had DECnet and LAT at a very early date; at least I
remember the sales droids trying to talk that up. However, if it didn't
have it, then that wouldn't surprise me. The effect of the cancellation
of the 36 bit line was nothing short of electrifying.? I think my
favorite quote was Ralph Gorin, upon being promised something which
paraphrased, went something like this, "You're asking us to jump out the
window under the assurance that you will have a net ready before we hit
the floor."
On 3/5/20 12:26 PM, John Forecast wrote:
I just tried using this syntax with Ultrix 2.2 and
Ultrix 4.0 and
neither accepted that format.
9:26 p.m.
On Mar 5, 2020, at 1:38 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
That's interesting; I thought I recognized the format. I wonder where in the world I
could be remembering it from? It is surely not parsed by either COMND% or GTJFN% and I
don't believe Tops-20 NFT currently allows it. However, I haven't really gotten
into tinkering with NFT, yet. I'm finishing up some changes to FAL and DAP and then
I'm probably going to work with Johnny a bit to iron out some oddities in the email
interface (SMTP DECnet and Tops-20 MAIL11).
I keep thinking about implementing rename in Tops-20 DAP, but I just stumbled over what
appears to be a BLISS based implementation of FAL and DAP which MRC never seems to have
put up. Maybe it's great.
So what era does Ultrix 2.2 hail from? I believe we had an early version, something like
1986 or 1987. However, I doubt they put that syntax in and then took it out. So do I
understand that DECnet wouldn't have been available on Ultrix 1.x? I can't
remember what version we had, which is remarkable because I wrote the entire Id system for
it (using Ingress).
DECnet-Ultrix 2.2 is from 1988. There was a version of DECnet for Ultrix 1.x, I
think it was 1.2, but it did not have LAT support included. At the end of the
DECnet-Ultrix 1.0 project I had a couple of weeks waiting for the next project to get spun
up so I implemented LAT host support. Then I found out that the LAT implementation had
been promised to the O/S group and, in particular, someone I had been working closely
with! I don?t think they ever shipped my implementation.
We appreciated some aspects of Ultrix; as I recall, it
had both System V and BSD functionality. I used the System V semaphore interface to
implement locking for the Id system. That much I remember; wrapping the calls in routines
called P(); and V(); (obviously). Regretfully, this is the only Dutch I ever learned...
I thought Ultrix had DECnet and LAT at a very early date; at least I remember the sales
droids trying to talk that up. However, if it didn't have it, then that wouldn't
surprise me. The effect of the cancellation of the 36 bit line was nothing short of
electrifying. I think my favorite quote was Ralph Gorin, upon being promised something
which paraphrased, went something like this, "You're asking us to jump out the
window under the assurance that you will have a net ready before we hit the floor."
On 3/5/20 12:26 PM, John Forecast wrote:
> I just tried using this syntax with Ultrix 2.2 and Ultrix 4.0 and neither accepted
that format.
7:32 p.m.
On Mar 5, 2020, at 10:31 AM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
I never heard of DECnet on SCO, but we ran Ultrix on the first (8650) and second (8700)
VAX's which we got at the data center for instructional use. My last use of SCO in
the early 2000's timeframe struck me as a product that was behind the times. It still
didn't have some features that Ultrix had; Linux and Digital Unix (1990's Alpha)
had far passed it by.
As I recall, Ultrix would accept node"user password account"::, the account
being necessary because the 20's ran real accounting. ... We discouraged
node"user password account":: as this would allow shoulder surfing. We may have
modified some of the Ultrix source to refuse this nomenclature.
The three part access control data is DECnet standard, but many systems only use two
parts. RSTS uses the third to carry the "system password" which is a second
system-wide password that can be enabled for additional security.
For the shoulder surfing concern, RSTS NFT will prompt for access control (with echo
disabled for the password) if the quoted elements are absent.
paul
7:39 p.m.
On 2020-03-05 19:32, Paul Koning wrote:
RSX ignores the account field, but it is possible to provide for other
systems that do happen to care.
Accounting in RSX is related to the user, so it's tracked by
user/password only. There are accounts, but you cannot select such
things, or change between multiple ones for one user.
I think VMS is exactly the same. I am a bit curious about how Tops-20
actually made use of them.
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
On Mar 5, 2020, at 10:31 AM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
I never heard of DECnet on SCO, but we ran Ultrix on the first (8650) and second (8700)
VAX's which we got at the data center for instructional use. My last use of SCO in
the early 2000's timeframe struck me as a product that was behind the times. It still
didn't have some features that Ultrix had; Linux and Digital Unix (1990's Alpha)
had far passed it by.
As I recall, Ultrix would accept node"user password account"::, the account
being necessary because the 20's ran real accounting. ... We discouraged
node"user password account":: as this would allow shoulder surfing. We may have
modified some of the Ultrix source to refuse this nomenclature.
The three part access control data is DECnet standard, but many systems only use two
parts. RSTS uses the third to carry the "system password" which is a second
system-wide password that can be enabled for additional security.
For the shoulder surfing concern, RSTS NFT will prompt for access control (with echo
disabled for the password) if the quoted elements are absent.
8:04 p.m.
Tops-20 will allow multiple accounts for a user and this was used at a
number of university sites that I knew of (but not all).? It had a
certain amount of flexibility that I have not often seen.
The university had a small commercial programming department (of one or
two programmers), yet a number of clients.? If you had to do some work
for one client, then you would switch your account to that client's with
a "SET ACCOUNT" command along with a remark as to why you did that.? On
occasion, a systems programmer or user services consultant could be
drafted to do some development and we would switch from university
overhead accounts (systems programming was I-X-CU-SY) to whatever the
client was and switch back when done.
No login or logout was necessary to do this.? Under normal conditions,
you could not use an account to which you were not authorized.? Account
usage was strictly enforced and also formed one basis for the class
scheduler, determining what share of the processor you could hope for.
The default account (if one is wanted) can be stored in the Tops-20
login directory (I don't recall whether it is in the FDB or not).? This
means that you can connect (via TELNET, FTP and FAL) without having to
type an account anywhere. /However/, if no default is specified in the
login directory, then you MUST give it or you won't be able to get any
service.? The FAL and FTP server ANONYMOUS code will allow account
specification.? I guess I put it in out of habit...
With the exception of IBM z/OS (n?e MVS/TSO), I am unaware of any
operating system that has that degree of granularity of accounting.? Job
cards for accounting still exist in JCL, but I don't remember how this
was handled in TSO.
I would assume that VMS could provide similar services, but I never
administered a installation.? I can't remember how (or if) we did
accounting on Ultrix, either.? I think we did.
On 3/5/20 1:39 PM, Johnny Billquist wrote:
Accounting in RSX is related to the user, so it's
tracked by
user/password only. There are accounts, but you cannot select such
things, or change between multiple ones for one user.
I think VMS is exactly the same. I am a bit curious about how Tops-20
actually made use of them.
? Johnny
6 Mar
6 Mar
12:08 a.m.
On Thu, Mar 5, 2020 at 11:05 AM Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
With the exception of IBM z/OS (n?e MVS/TSO), I am
unaware of any
operating system that has that degree of granularity of accounting. Job
cards for accounting still exist in JCL, but I don't remember how this was
handled in TSO.
Under MVS basically everything is a "batch" job from what I remember.
In SDSF or Q, a logged-on TSO user (Job # TSUnnnn) shows a JOB card with
some accounting info and other parameters.
I believe the EXEC statement PGM=IKJEFT01 but it's been a while.
5 Mar
5 Mar
6:01 p.m.
On Mar 5, 2020, at 8:09 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2020-03-04 20:59, John Forecast wrote:
I think access control allows either nodename/user/password/account:: or
nodename"user password":: everywhere.
Yes, you?re right. I don?t remember ever using the quote format.
John.
On Mar 3,
2020, at 10:38 PM, Robert Armstrong <bob at jfcl.com> wrote:
Here?s a few more:
DECnet-RSX
Kernel interface requires a node name (up to 6 characters) so can only connect to nodes
which are in the system database.
Access control uses the syntax nodename/user/password/account:: The area.node notation, and the Phase 3 numeric
address notation, were
intended to be standard, not just limited to NCP. And indeed DECnet/E
(in RSTS) does both:
FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
2064::. It also accepts the node"name password":: notation as well.
Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
implementations. Are there systems that don't?
And the VMS parser doesn't limit the node name to 6 characters, so you can
say "63.1023::" (although HECnet has no such node).
Bob
However, only NCP allows numeric addresses. Anything
else needs the nodename. But within NCP you can play using node numbers everywhere just
fine.
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
4 Mar
4 Mar
5:05 a.m.
Huh, now that is interesting.? I guess that's something that never made
it into Tops-20, although it doesn't sound immediately difficult for
some functionality to be implemented in NFT.? The 1982 DECnet-20 User
Guide that I have is very specific that _only_ names (SIXBIT subset)?
can be given to GTJFN%. But it may be out of date or may have never been
updated.
The GTJFN% file parsing code is formidable; not a few hours to look
through, so I won't be looking at that tonight.? It seems to me that a
very simple experiment will suffice: undefine a node (assuming the -1
undocumented feature works) and then see what breaks.? The most
important area would be the NICE handler, NMLT20.? If that can't do a
TELL to an undefined node, then that is pretty definitive.
NFT will not parse for an area.number, although it could be made to
(with sufficient coaxing).? It's using COMND% and GTJFN% to parse for
the node name, so alternate parse tables would need to be done.?
However, that still leaves you with the fact that you would need to pump
those numbers through the .NDRNN function of the NODE% JSYS if you were
going to get anywhere.
Regretfully, I do not appear to have sources for NMLT20, so I can't tell
what it does.? The parse tables for it (NCPTAB) accept an area.number,
but I don't see that anything in the Tops-20 operator interface resolves
it as above (Tops-10 does).
I'll tinker with it some more.? Wish I could find another Galaxy nerd,
but we were very rare.
------------------------------------------------------------------------
On 3/3/20 8:34 PM, Paul Koning wrote:
The area.node notation, and the Phase 3 numeric address notation, were intended to be
standard, not just limited to NCP. And indeed DECnet/E (in RSTS) does both:
$ dir 1.13::[decnet]nodenames.dat;0
Node: 1.13
User: guest
Password:
System Password:
Directory 1.13::DU1:[DECNET]
Name .Typ Size Prot Access Date Time UIC
NODENAMES.DAT;254 30/30 < 40> 28-Feb-20 28-Feb-20 01:08 [7,14]
Total of 30/30 blocks in 1 file.
$ dir 1037::[decnet]nodenames.dat;0
Node: 1037
User: guest
Password:
System Password:
Directory 1037::DU1:[DECNET]
Name .Typ Size Prot Access Date Time UIC
NODENAMES.DAT;254 30/30 < 40> 28-Feb-20 28-Feb-20 01:08 [7,14]
Total of 30/30 blocks in 1 file.
These are DECnet kernel features. The connect call takes a 6-character ASCII node
argument, and if that's numeric string (possibly with a . in it) it's interpreted
as a node number in the way shown. Of course, 63.1023 doesn't fit in 6 characters so
for that one you'd be forced to write it as 65535.
paul
> ------------------------------------------------------------------------
> On Mar 3, 2020, at 6:57 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> You've put your finger on something that's puzzled me for quite some time
about Tops-20's lexical implementation.
>
> There is no standardized syntax in the generalized parsing interface (COMND% and
GTJFN%) for using numeric node names. If you ask COMND% to parse a node name and do not
shut off standard syntax, then you must specify a maximum six character word which
conforms to the SIXBIT character set followed a double colon, which looks like what you
would think it would, viz: VENTI2::
>
> However, the integration into the monitor isn't as seamless as it appears to be
under VMS. In order to make a connection, you must build a special string for GTJFN% to
swallow. Let's suppose I wanted to grab the latest node list from MIM:: (which I do
on a weekly basis); you would type MIM::FIX.T20;0 as the source to NFT. That's not
what GTJFN% wants and you must transmogrify the string into DCN:MIM-FAL. Once that
connection is open, you negotiate DAP and then ask MIM:: to send the file.
>
> There is no standardized "[a.b.c.d]" syntax such as what you might use to
get to an IP4 host which is neither in the DNS nor host tables. You can use COMND% to
parse for a number optionally followed by a dot and another number and the operator NICE
interface (NCP) does in fact do this. Indeed, it is the only interface besides SETNOD
which does this (in order to define nodes). So I can give an area.address to NCP as an
argument to a TELL verb in order to get remote information.
> ...
>
> Curiouser and curiouser. Do the above two functionalities exist in other operating
systems?
>
7 Mar
7 Mar
6:41 p.m.
On 2020-03-04 00:57, Thomas DeBellis wrote:
However, as I've said before (viz., the NFT:
device and FTS), there are
parts of Tops-20 DECnet that strike me as not fully productized.? One
example is that there is no way for /anybody/ to extract the area and
number of a node once it is the monitor.? You can (and should) verify
that the node is 'legitimate' by using .NDVFY function of the NODE%
JSYS, which will also tell you some interesting things about it.
However, it will not divulge the aforementioned numbers.? It annoyed me
enough so that I modified the monitor to do just that with an additional
function, .NDVFX and I use this in DAP (but don't depend on it) and in
the mailer (where I do).
I haven't posted the changes anywhere because I can't make up my mind
whether this was fixing an oversight or breaking a design decision or
indeed, whether that should even matter.
In RSX there is no documented way to map between node names and
addresses, in either direction.
There is an interface for it, but it's not documented. Internally,
DECnet have a separate device and ACP which handles the nodename
database. If you just have the specifications for this device, you can
do lookups yourself, but DEC never intended that anyone should use it,
except DECnet internally does.
Another example is that, once a node is inserted into
the monitor data
base, there is *no* documented way to remove it.? As I was implementing
.NDVFX, I was looking at the in-area hashing code and noticed that it
appears that the monitor will remove a node marked as -1 (36 bits).? I
have yet to test this.? Certainly SETNOD gives no hint (another reason
I'm toying with a rewrite).
Curiouser and curiouser.? Do the above two functionalities exist in
other operating systems?
The ability to remove nodes from the nodename database works fine in
pretty much all OSes I know of, except for the PDP-10 world.
In VMS and RSX, it's NCP CLEAR NODE node ALL, for example, for the
current running system. In VMS you use PURGE in NCP for the permanent
database, while in RSX, you use PURGE, but in CFE, which is the
configuration file editor, for the permanent database.
I think RSTS/E does it all through NCP, like in VMS, but I guess Paul
can tell for sure.
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
7:48 p.m.
That's interesting that there is no user visible interface to map
between nodes and area.numbers in RSX, just like Tops-20.? I wonder
why?? As a contrast, we all know that IP4 and IP6 addresses can be
specified both numerically and 'symbolically' via the DNS. However, the
functionality existed in the HOSTS file and predates IP.
Tops-20 does not precisely have a permanent node database. Everything is
configured and loaded either from text files or 'compiled' text files on
boot up.? So initial configuring for DECnet and setting the local node
name and type is done in CONFIG.CMD which is parsed by SETSPD before
Galaxy is initiated. While that is happening, the 'compiled' (I.E.,
binary) node database is inserted into the hash table.? SETNOD does not
have full functionality to add and remove nodes from this table,
although it can tell the monitor to remove a node.
After the insert is done, enough functionality is available for
SYSTEM.CMD to be parsed by OPR and issue the remaining NCP commands to
the local NICE processor (NMTL20).? Strangely enough, CLEAR NODE xx::
ALL didn't have any effect.? It probably should have.? PURGE didn't work
at all.? So, you have to do the (undocumented) SETNOD feature to remove
a node.
!opr
OPR>ent ncp
NCP>push
?PANDA TOPS-20 Command processor 7.1(4454)-5
?End of TOMMYT:<SLOGIN>COMAND.CMD.12
@i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
@pop
NCP>tel ziti:: shoW eXECUTOR
NCP>
13:31:21 ??? NCP
??? ??? Request # 11 Accepted
NCP>
13:31:21 ??? NCP
Request # 11; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>clEAR noDE ziti:: alL
NCP>
13:31:42 ??? NCP
Request # 12; Clear Node Completed
NCP>telL ziti:: shoW exECUTOR
NCP>
13:31:58 ??? NCP
??? ??? Request # 13 Accepted
NCP>
13:31:59 ??? NCP
Request # 13; Show Executor Node Summary Completed
Executor Node = 2.16 (ZITI)
? Circuit = eth1
? State = On
? Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>push
@i dec
?Local DECNET node: VENTI2.? Nodes reachable: 6.
?Accessible DECNET nodes are:??? A2RTR??? APOLLO LEGATO??? TOMMYT???
VENTI2??? ZITI
@pop
NCP>purGE noDE ziti:: alL
NCP>
13:45:47 ??? NCP
Request # 14; Purge Node Failed, Operation failure
NCP>
------------------------------------------------------------------------
On 3/7/20 12:41 PM, Johnny Billquist wrote:
On 2020-03-04 00:57, Thomas DeBellis wrote:
However, as I've said before (viz., the NFT:
device and FTS), there
are parts of Tops-20 DECnet that strike me as not fully productized.?
One example is that there is no way for /anybody/ to extract the area
and number of a node once it is the monitor.? You can (and should)
verify that the node is 'legitimate' by using .NDVFY function of the
NODE% JSYS, which will also tell you some interesting things about
it. However, it will not divulge the aforementioned numbers.? It
annoyed me enough so that I modified the monitor to do just that with
an additional function, .NDVFX and I use this in DAP (but don't
depend on it) and in the mailer (where I do).
I haven't posted the changes anywhere because I can't make up my mind
whether this was fixing an oversight or breaking a design decision or
indeed, whether that should even matter.
In RSX there is no documented way to map between node names and
addresses, in either direction.
There is an interface for it, but it's not documented. Internally,
DECnet have a separate device and ACP which handles the nodename
database. If you just have the specifications for this device, you can
do lookups yourself, but DEC never intended that anyone should use it,
except DECnet internally does.
Another example is that, once a node is inserted
into the monitor
data base, there is *no* documented way to remove it.? As I was
implementing .NDVFX, I was looking at the in-area hashing code and
noticed that it appears that the monitor will remove a node marked as
-1 (36 bits).? I have yet to test this.? Certainly SETNOD gives no
hint (another reason I'm toying with a rewrite).
Curiouser and curiouser.? Do the above two functionalities exist in
other operating systems?
The ability to remove nodes from the nodename database works fine in
pretty much all OSes I know of, except for the PDP-10 world.
In VMS and RSX, it's NCP CLEAR NODE node ALL, for example, for the
current running system. In VMS you use PURGE in NCP for the permanent
database, while in RSX, you use PURGE, but in CFE, which is the
configuration file editor, for the permanent database.
I think RSTS/E does it all through NCP, like in VMS, but I guess Paul
can tell for sure.
? Johnny
8:20 p.m.
On Mar 7, 2020, at 12:41 PM, Johnny Billquist <bqt
at softjar.se> wrote:
...
The ability to remove nodes from the nodename database works fine in pretty much all OSes
I know of, except for the PDP-10 world.
In VMS and RSX, it's NCP CLEAR NODE node ALL, for example, for the current running
system. In VMS you use PURGE in NCP for the permanent database, while in RSX, you use
PURGE, but in CFE, which is the configuration file editor, for the permanent database.
I think RSTS/E does it all through NCP, like in VMS, but I guess Paul can tell for sure.
Correct. RSTS (DECnet/E) fairly closely follows the network management architecture, and
in particular it has the volatile and permanent database distinction and the ability to
add, delete, or modify in either with the standard syntax.
paul
1534
days inactive
1538
days old
26 comments
9 participants
participants (9)
-
bob＠jfcl.com -
bqt＠softjar.se -
john＠forecast.name -
jrbrady65＠gmail.com -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
steve＠davidson.net -
supratim＠riseup.net -
tommytimesharing＠gmail.com