10 Apr
2023
10 Apr
'23
11:58 p.m.
Now that I'm done with Kermit-20, I wanted to get back to finishing up
some other work that I had been doing. FAL, DAP and NFT are in good
enough shape for me to leave them alone for the moment, so that's
another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR (SMTP
over DECnet). Fixing this required modifying DDT, which I had to do to
fix another issue I had introduced into Kermit. I wanted to have a
quick look at what Tops-20 hosts might be up on HECnet and wrote up a
little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It builds
a connection the NCU's of various nodes to determine the path that a
message might take to get there. Think of it like traceroute or ping -R
(RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / NI-0-0 <= TOMMYT (2.520) 1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
11 Apr
11 Apr
12:30 a.m.
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE
message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure
if it's just an old version of PYRTR, or if there is something for Paul
to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet most
certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
Now that I'm done with Kermit-20, I wanted to get
back to finishing up
some other work that I had been doing. FAL, DAP and NFT are in good
enough shape for me to leave them alone for the moment, so that's
another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR (SMTP
over DECnet). Fixing this required modifying DDT, which I had to do to
fix another issue I had introduced into Kermit. I wanted to have a
quick look at what Tops-20 hosts might be up on HECnet and wrote up a
little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It builds
a connection the NCU's of various nodes to determine the path that a
message might take to get there. Think of it like traceroute or ping -R
(RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / NI-0-0 <= TOMMYT (2.520) 1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
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
1:34 a.m.
On Apr 10, 2023, at 6:30 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that
generates the same request as NCP SHO NOD do.
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
It's because "show node" looks at the L1 forwarding tables. That's
obviously not the whole answer for an area router. I don't remember what the Netman
spec says. Typically I do what it calls for but this may be an omission. Then again,
even if what I do is compliant it doesn't mean I shouldn't do better, as RSX
does.
Also, note that this will give the forward path, which
in DECnet most certainly might be different than the return path...
And more precisely, it gives one forward path; if a router does path splitting that
isn't represented in the data you get back.
One small issue, more for the HECnet mapper than for a traceroute service: RSTS nodes get
some of this stuff wrong. I annotated some of it in the mapper code. I think next node
may not come back all the time, and I know for sure that adjacent node type is encoded
incorrectly.
paul
2:03 a.m.
On 2023-04-11 01:34, Paul Koning wrote:
Well, next node should really be next node. No matter if that is L1 or L2.
I checked and both VMS and RSX certainly tells the next node as you
would expect.
Not sure which other type of system I could check this on. I don't think
RSTS/E or TOPS-20 can act as area router. And Cisco don't speak NICE in
the first place.
True. In that case, you get one answer, but there might be another with
the same cost, which you will not find out.
On Apr 10, 2023, at 6:30 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that
generates the same request as NCP SHO NOD do.
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
It's because "show node" looks at the L1 forwarding tables. That's
obviously not the whole answer for an area router. I don't remember what the Netman
spec says. Typically I do what it calls for but this may be an omission. Then again,
even if what I do is compliant it doesn't mean I shouldn't do better, as RSX does.
Also, note
that this will give the forward path, which in DECnet most certainly might be different
than the return path...
And more precisely, it gives one forward path; if a router does path splitting that
isn't represented in the data you get back. One small issue, more for the HECnet mapper than for a
traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it in
the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-)
Anyway, looking at a remote RSTS/E node from MIM:
.ncp tell pirsts sho exec
Node summary as of 11-APR-23 02:01:42
Executor node = 29.205 (PIRSTS)
State = On, Identification = DECnet/E V4.1
Active links = 1
.ncp tell pirsts sho nod mim
Node summary as of 11-APR-23 02:01:20
Remote Active Next
Node State Links Delay Circuit Node
1.13 (MIM) 1 5 QNA-0 29.206 (ONAPI4)
So it do look like the next node info is good there too.
And I've also looked at TOPS-20 machines, and it looks good on those too.
But yeah, adjacent node requests to RSTS/E gives back unexpected nodes.
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
2:19 a.m.
On Apr 10, 2023, at 8:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 01:34, Paul Koning wrote:
Well, next node should really be next node. No matter if that is L1 or L2.
Correct, and it will be when I get my new code published.
On Apr
10, 2023, at 6:30 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that
generates the same request as NCP SHO NOD do.
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
It's because "show node" looks at the L1 forwarding
tables. That's obviously not the whole answer for an area router. I don't
remember what the Netman spec says. Typically I do what it calls for but this may be an
omission. Then again, even if what I do is compliant it doesn't mean I shouldn't
do better, as RSX does. I checked and both VMS and RSX certainly tells the
next node as you would expect.
Not sure which other type of system I could check this on. I don't think RSTS/E or
TOPS-20 can act as area router. And Cisco don't speak NICE in the first place.
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently.
Also, note that this will give the forward path, which
in DECnet most certainly might be different than the return path...
And more
precisely, it gives one forward path; if a router does path splitting that isn't
represented in the data you get back. One small issue, more for the HECnet mapper than
for a traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it
in the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-) Anyway, looking at a remote RSTS/E node from MIM:
.ncp tell pirsts sho exec
Node summary as of 11-APR-23 02:01:42
Executor node = 29.205 (PIRSTS)
State = On, Identification = DECnet/E V4.1
Active links = 1
.ncp tell pirsts sho nod mim
Node summary as of 11-APR-23 02:01:20
Remote Active Next
Node State Links Delay Circuit Node
1.13 (MIM) 1 5 QNA-0 29.206 (ONAPI4)
So it do look like the next node info is good there too.
And I've also looked at TOPS-20 machines, and it looks good on those too.
But yeah, adjacent node requests to RSTS/E gives back unexpected nodes.
You mean "show adjacent nodes"? Right, I noted that as another bug. I
don't even want to imagine what it does about "significant nodes", one of
the more obscure NICE features.
paul
2:41 a.m.
On 2023-04-11 02:19, Paul Koning wrote:
Excellent. I sometimes use this information when trying to understand
what is going on in HECnet, so this will be of some value.
Hmm. Yeah, not sure I know of any RSTS/E acting as any kind of router.
Maybe someone else knows of one?
As for node type, right. Checked RSX now, and it only reports this for
adjacent nodes. Empty field for others.
But not sure how the mapper would use it. The mapper is talking to each
node anyway, right? And getting type from there.
Or would you use this to not even go talking to endnodes?
True. In that case, you get one answer, but there might be another with the same cost,
which you will not find out.
I should look for it again. That code isn't too easy to grok.
Not sure any hints from the RSX code would help, but let me know if you
want me to dig around.
Yeah. I basically get every node the RSTS/E system knows about, which
obviously are not only adjacent nodes.
Haven't even tried significant nodes... :-)
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
On Apr 10, 2023, at 8:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 01:34, Paul Koning wrote:
Well, next node should really be next node. No matter if that is L1 or L2.
Correct, and it will be when I get my new code published. On Apr
10, 2023, at 6:30 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that
generates the same request as NCP SHO NOD do.
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
It's because "show node" looks at the L1 forwarding
tables. That's obviously not the whole answer for an area router. I don't
remember what the Netman spec says. Typically I do what it calls for but this may be an
omission. Then again, even if what I do is compliant it doesn't mean I shouldn't
do better, as RSX does. I checked and
both VMS and RSX certainly tells the next node as you would expect.
Not sure which other type of system I could check this on. I don't think RSTS/E or
TOPS-20 can act as area router. And Cisco don't speak NICE in the first place.
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently. Also, note
that this will give the forward path, which in DECnet most certainly might be different
than the return path...
And more precisely, it gives one forward path; if a router
does path splitting that isn't represented in the data you get back. One small issue, more for the HECnet mapper than
for a traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it
in the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-) Anyway,
looking at a remote RSTS/E node from MIM:
.ncp tell pirsts sho exec
Node summary as of 11-APR-23 02:01:42
Executor node = 29.205 (PIRSTS)
State = On, Identification = DECnet/E V4.1
Active links = 1
.ncp tell pirsts sho nod mim
Node summary as of 11-APR-23 02:01:20
Remote Active Next
Node State Links Delay Circuit Node
1.13 (MIM) 1 5 QNA-0 29.206 (ONAPI4)
So it do look like the next node info is good there too.
And I've also looked at TOPS-20 machines, and it looks good on those too.
But yeah, adjacent node requests to RSTS/E gives back unexpected nodes.
You mean "show adjacent nodes"? Right, I noted that as another bug. I
don't even want to imagine what it does about "significant nodes", one of
the more obscure NICE features.
2:47 a.m.
On Apr 10, 2023, at 8:41 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 02:19, Paul Koning wrote:
Yes. And also to know the type of nodes that don't accept NICE connections.
...
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently.
Hmm. Yeah, not sure I know of any RSTS/E acting as any kind of router. Maybe someone else
knows of one?
As for node type, right. Checked RSX now, and it only reports this for adjacent nodes.
Empty field for others.
But not sure how the mapper would use it. The mapper is talking to each node anyway,
right? And getting type from there.
Or would you use this to not even go talking to endnodes? > Also, note
that this will give the forward path, which in DECnet most certainly might be different
than the return path...
And more precisely, it gives one forward path; if a router does path splitting that
isn't represented in the data you get back.
True. In that case, you get one answer, but there might be another with the same cost,
which you will not find out.
One small issue, more for the HECnet mapper than
for a traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it
in the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-)
2:58 a.m.
On 2023-04-11 02:47, Paul Koning wrote:
Not sure you would be able to tell. Type says if it's an endnode, L1 or
L2 router. Nothing else, as far as I've ever seen.
Looking at KRYLBO::
.ncp tell krylbo sho adj nod stat
Adjacent nodes status as of 11-APR-23 02:52:29
Remote Active
Node State Links Delay Type Cost Hops
Circuit
1.13 (MIM) 1 5 Area 10 1 IP-0-0
59.1016 (STORTR) Area 9 2 QNA-0
59.1017 (HOBBY2) Area 4 1 QNA-0
59.1018 (HOBBYH) Area 4 1 QNA-0
MIM is obviously RSX.
STORTR and HOBBYH are PyDECnet, but I believe that HOBBY2 might be a
Cisco box. Anyway, it's clearly up and running, but not responding to NICE.
Hmm. I just noticed that STORTR is actually coming through HOBBYH, so
apparently type can be reported for non-adjacent nodes sometimes.
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
On Apr 10, 2023, at 8:41 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 02:19, Paul Koning wrote:
Yes. And also to know the type of nodes that don't accept NICE connections. ...
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently.
Hmm. Yeah, not sure I know of any RSTS/E acting as any kind of router. Maybe someone else
knows of one?
As for node type, right. Checked RSX now, and it only reports this for adjacent nodes.
Empty field for others.
But not sure how the mapper would use it. The mapper is talking to each node anyway,
right? And getting type from there.
Or would you use this to not even go talking to endnodes?
2:31 p.m.
On Apr 10, 2023, at 8:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Not sure you would be able to tell. Type says if it's an endnode, L1 or L2 router.
Nothing else, as far as I've ever seen.
Looking at KRYLBO::
.ncp tell krylbo sho adj nod stat
Adjacent nodes status as of 11-APR-23 02:52:29
Remote Active
Node State Links Delay Type Cost Hops Circuit
1.13 (MIM) 1 5 Area 10 1 IP-0-0
59.1016 (STORTR) Area 9 2 QNA-0
59.1017 (HOBBY2) Area 4 1 QNA-0
59.1018 (HOBBYH) Area 4 1 QNA-0
MIM is obviously RSX.
STORTR and HOBBYH are PyDECnet, but I believe that HOBBY2 might be a Cisco box. Anyway,
it's clearly up and running, but not responding to NICE.
Hmm. I just noticed that STORTR is actually coming through HOBBYH, so apparently type can
be reported for non-adjacent nodes sometimes.
It's possible for a node to be adjacent but routed via two hops -- if the circuit cost
is greater than the path cost of that two-hop path. Not common but it can happen. If so,
the node type would be known from the circuit state. That's presumably the case here,
with NCP picking up the list of adjacent nodes from the circuit state and then doing read
node status for each node it found.
paul
...
Or would you use this to not even go talking to endnodes?
Yes. And also to know
the type of nodes that don't accept NICE connections.
4:19 p.m.
On 2023-04-11 14:31, Paul Koning wrote:
Good catch. Indeed, KRYLBO do also have a direct link with STORTR, but
that one have a cost of 10.
Didn't consider that possibility. :-)
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
On Apr 10, 2023, at 8:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Not sure you would be able to tell. Type says if it's an endnode, L1 or L2 router.
Nothing else, as far as I've ever seen.
Looking at KRYLBO::
.ncp tell krylbo sho adj nod stat
Adjacent nodes status as of 11-APR-23 02:52:29
Remote Active
Node State Links Delay Type Cost Hops Circuit
1.13 (MIM) 1 5 Area 10 1 IP-0-0
59.1016 (STORTR) Area 9 2 QNA-0
59.1017 (HOBBY2) Area 4 1 QNA-0
59.1018 (HOBBYH) Area 4 1 QNA-0
MIM is obviously RSX.
STORTR and HOBBYH are PyDECnet, but I believe that HOBBY2 might be a Cisco box. Anyway,
it's clearly up and running, but not responding to NICE.
Hmm. I just noticed that STORTR is actually coming through HOBBYH, so apparently type can
be reported for non-adjacent nodes sometimes.
It's possible for a node to be adjacent but routed via two hops -- if the circuit
cost is greater than the path cost of that two-hop path. Not common but it can happen.
If so, the node type would be known from the circuit state. That's presumably the
case here, with NCP picking up the list of adjacent nodes from the circuit state and then
doing read node status for each node it found. ...
Or would you use this to not even go talking to endnodes?
Yes. And also to know
the type of nodes that don't accept NICE connections.
2:04 a.m.
On Apr 10, 2023, at 6:30 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
This will be in the next drop of T1.1 -- I should get that wrapped up.
The right algorithm is to use the "nearest L2 router" info if it's out of
area and this is an L1 router, or the area routing data if it's an L2 router. Also,
if the destination is out of area, then "status" should omit hops/cost since
they are not accurately known. I have all that coded.
paul
2:16 a.m.
On 2023-04-11 02:04, Paul Koning wrote:
Great.
On Apr 10, 2023, at 6:30 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
This will be in the next drop of T1.1 -- I should get that wrapped up. The right algorithm is to use the "nearest L2
router" info if it's out of area and this is an L1 router, or the area routing
data if it's an L2 router. Also, if the destination is out of area, then
"status" should omit hops/cost since they are not accurately known. I have all
that coded.
Uh? Are you sure about that? If you are an L1 router, then it should be
the next hop towards the L2 router, and that isn't necessarily the same
as the L2 router...
Hops/cost sounds right, though. Not shown on RSX in that circumstance
either, obviously.
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
2:21 a.m.
On Apr 10, 2023, at 8:16 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 02:04, Paul Koning wrote:
Great.
I meant that it uses the information for the adjacency in forwarding table entry 0, in
other words the adjacency that points towards the nearest L2 router. So yes, it will
report whoever is the neighbor on that path.
paul
On Apr
10, 2023, at 6:30 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
This will be in the next drop of T1.1 -- I should get that wrapped up.
The right algorithm is to use the "nearest
L2 router" info if it's out of area and this is an L1 router, or the area routing
data if it's an L2 router. Also, if the destination is out of area, then
"status" should omit hops/cost since they are not accurately known. I have all
that coded.
Uh? Are you sure about that? If you are an L1 router, then it should be the next hop
towards the L2 router, and that isn't necessarily the same as the L2 router...
2:37 a.m.
It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few commands
would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
Could you tell in detail which NICE messages you are
generating?
In general, if I were to do such a tool, I would normally do the NICE
message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure
if it's just an old version of PYRTR, or if there is something for
Paul to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet most
certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
Now that I'm done with Kermit-20, I wanted to
get back to finishing
up some other work that I had been doing. FAL, DAP and NFT are in
good enough shape for me to leave them alone for the moment, so
that's another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR
(SMTP over DECnet). Fixing this required modifying DDT, which I had
to do to fix another issue I had introduced into Kermit. I wanted to
have a quick look at what Tops-20 hosts might be up on HECnet and
wrote up a little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It
builds a connection the NCU's of various nodes to determine the path
that a message might take to get there. Think of it like traceroute
or ping -R (RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / NI-0-0 <= TOMMYT (2.520)
1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
2:42 a.m.
Obviously, there is no good reason to ask for the circuit information.
You already got all you needed from the show node xx status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few commands
would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
--
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
Could you tell in detail which NICE messages you
are generating?
In general, if I were to do such a tool, I would normally do the NICE
message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure
if it's just an old version of PYRTR, or if there is something for
Paul to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet most
certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Now that I'm done with Kermit-20, I wanted to
get back to finishing
up some other work that I had been doing. FAL, DAP and NFT are in
good enough shape for me to leave them alone for the moment, so
that's another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR
(SMTP over DECnet). Fixing this required modifying DDT, which Ihad
to do to fix another issue I had introduced into Kermit. I wanted to
have a quick look at what Tops-20 hosts might be up on HECnet and
wrote up a little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It
builds a connection the NCU's of various nodes to determine the path
that a message might take to get there. Think of it like traceroute
or ping -R (RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520)
1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
2:54 a.m.
I don't have an informed opinion yet, as I only just started looking.
The code is kind of odd in that it is half Tops-10 and half Tops-20, but
not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct. Now, if
I just look at the show node /xxx/status, I was wondering about something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
Obviously, there is no good reason to ask for the
circuit information.
You already got all you needed from the show node xx status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few
commands would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
Could you tell in detail which NICE messages you
are generating?
In general, if I were to do such a tool, I would normally do the
NICE message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not
sure if it's just an old version of PYRTR, or if there is something
for Paul to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet
most certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Now that I'm done with Kermit-20, I wanted to
get back to finishing
up some other work that I had been doing. FAL, DAP and NFT are in
good enough shape for me to leave them alone for the moment, so
that's another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR
(SMTP over DECnet). Fixing this required modifying DDT, which Ihad
to do to fix another issue I had introduced into Kermit. I wanted
to have a quick look at what Tops-20 hosts might be up on HECnet
and wrote up a little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It
builds a connection the NCU's of various nodes to determine the
path that a message might take to get there. Think of it like
traceroute or ping -R (RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if
anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520)
1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
-1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
-1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3 a.m.
That's what the thread between me and Paul right now is about. And Paul
have this fixed in his code now. Next version should have it fixed.
Johnny
On 2023-04-11 02:54, Thomas DeBellis wrote:
I don't have an informed opinion yet, as I only
just started looking.
The code is kind of odd in that it is half Tops-10 and half Tops-20, but
not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct. Now, if
I just look at the show node /xxx/status, I was wondering about something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
--
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
Obviously, there is no good reason to ask for the
circuit information.
You already got all you needed from the show node xx status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few
commands would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
Could you tell in detail which NICE messages you
are generating?
In general, if I were to do such a tool, I would normally do the
NICE message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not
sure if it's just an old version of PYRTR, or if there is something
for Paul to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet
most certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
> Now that I'm done with Kermit-20, I wanted to get back to finishing
> up some other work that I had been doing. FAL, DAP and NFT are in
> good enough shape for me to leave them alone for the moment, so
> that's another rabbit hole I've gotten myself out of.
>
> I'm now looking fix an error that I somehow introduced into MMAILR
> (SMTP over DECnet). Fixing this required modifying DDT, whichIhad
> to do to fix another issue I had introduced into Kermit. I wanted
> to have a quick look at what Tops-20 hosts might be up on HECnet
> and wrote up a little batch job to use NETPTH to test connectivity.
>
> NETPTH is a nifty utility to find paths between DECnet nodes. It
> builds a connection the NCU's of various nodes to determine the
> path that a message might take to get there. Think of it like
> traceroute or ping -R (RECORD_ROUTE option).
>
> It almost never works...
>
> Before I roll up my sleeves and jump into this I was wondering if
> anybody had any observations about the errors I'm seeing?
>
> ------------------------------------------------------------------------
>
>
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
> -1 -1
> A2RTR (2.1023) =>DMC-31 /
> ?NETCFO Can't find Output Circuit parameter
>
> *SAMT20*::
> ?NETURN Unreachable node
>
> *TOMMYT*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520)
> 1 1
>
> *BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
> -1 -1
> A2RTR (2.1023) =>
> ?NETCFO Can't find Output Circuit parameter
>
> *WALACH*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
> -1 -1
> A2RTR (2.1023) =>DMC-29-206 /
> ?NETCFO Can't find Output Circuit parameter
>
> *SOL*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
> -1 -1
> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
> -1 -1
> STORTR (59.1016) =>GRE-16 /
> ?NETCFO Can't find Output Circuit parameter
>
> *FENCER*::
>
> From Via Back Thru Cost Hops
> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
> -1 -1
> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
> -1 -1
> STORTR (59.1016) =>GRE-16 /
> ?NETPTH NTMAN failed, reason:
> Parameter missing
> $
>
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3:04 a.m.
Yes, I was catching up on that, but perhaps not keeping up with it...
So what's the bottom line here? Is netpth rolling over and dying
actually legitimate or is there a better algorithm to use?
On 4/10/23 9:00 PM, Johnny Billquist wrote:
That's what the thread between me and Paul right
now is about. And
Paul have this fixed in his code now. Next version should have it fixed.
Johnny
On 2023-04-11 02:54, Thomas DeBellis wrote:
I don't have an informed opinion yet, as I
only just started
looking. The code is kind of odd in that it is half Tops-10 and half
Tops-20, but not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct. Now,
if I just look at the show node /xxx/status, I was wondering about
something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
Obviously, there is no good reason to ask for the
circuit
information. You already got all you needed from the show node xx
status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few
commands would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
> Could you tell in detail which NICE messages you are generating?
>
> In general, if I were to do such a tool, I would normally do the
> NICE message that generates the same request as NCP SHO NOD do.
>
> To give an example from JOCKE to A2RTR:
>
> .ncp sho nod a2rtr
>
> Node summary as of 11-APR-23 00:26:52
>
> Remote Active Next
> Node State Links Delay Circuit Node
>
> 2.1023 (A2RTR) 1.15 (PONDUS)
>
> .ncp tell pondus sho nod a2rtr
>
> Node summary as of 11-APR-23 00:27:05
>
> Remote Active Next
> Node State Links Delay Circuit Node
>
> 2.1023 (A2RTR) 1.13 (MIM)
>
> .ncp tell mim sho nod a2rtr
>
> Node summary as of 11-APR-23 00:27:21
>
> Remote Active Next
> Node State Links Delay Circuit Node
>
> 2.1023 (A2RTR) 31.3 (PYRTR)
>
> .ncp tell pyrtr sho nod a2rtr
>
> Node summary as of 11-APR-23 00:27:30
>
> Remote Active Next
> Node State Links Delay Circuit Node
>
> 2.1023 (A2RTR)
>
>
>
> Sadly PYRTR did not actually tell what the next node is here. Not
> sure if it's just an old version of PYRTR, or if there is
> something for Paul to improve. But you should get the idea...
>
> Also, note that this will give the forward path, which in DECnet
> most certainly might be different than the return path...
>
> Johnny
>
>
> On 2023-04-10 23:58, Thomas DeBellis wrote:
>> Now that I'm done with Kermit-20, I wanted to get back to
>> finishing up some other work that I had been doing. FAL, DAP and
>> NFT are in good enough shape for me to leave them alone for the
>> moment, so that's another rabbit hole I've gotten myself out of.
>>
>> I'm now looking fix an error that I somehow introduced into
>> MMAILR (SMTP over DECnet). Fixing this required modifying DDT,
>> whichIhad to do to fix another issue I had introduced into
>> Kermit. I wanted to have a quick look at what Tops-20 hosts
>> might be up on HECnet and wrote up a little batch job to use
>> NETPTH to test connectivity.
>>
>> NETPTH is a nifty utility to find paths between DECnet nodes. It
>> builds a connection the NCU's of various nodes to determine the
>> path that a message might take to get there. Think of it like
>> traceroute or ping -R (RECORD_ROUTE option).
>>
>> It almost never works...
>>
>> Before I roll up my sleeves and jump into this I was wondering if
>> anybody had any observations about the errors I'm seeing?
>>
>> ------------------------------------------------------------------------
>>
>>
>>
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
>>
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>> -1 -1
>> A2RTR (2.1023) =>DMC-31 /
>> ?NETCFO Can't find Output Circuit parameter
>>
>> *SAMT20*::
>> ?NETURN Unreachable node
>>
>> *TOMMYT*::
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520)
>> 1 1
>>
>> *BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>> -1 -1
>> A2RTR (2.1023) =>
>> ?NETCFO Can't find Output Circuit parameter
>>
>> *WALACH*::
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>> -1 -1
>> A2RTR (2.1023) =>DMC-29-206 /
>> ?NETCFO Can't find Output Circuit parameter
>>
>> *SOL*::
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>> -1 -1
>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>> -1 -1
>> STORTR (59.1016) =>GRE-16 /
>> ?NETCFO Can't find Output Circuit parameter
>>
>> *FENCER*::
>>
>> From Via Back Thru Cost Hops
>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>> -1 -1
>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>> -1 -1
>> STORTR (59.1016) =>GRE-16 /
>> ?NETPTH NTMAN failed, reason:
>> Parameter missing
>> $
>>
>>
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3:09 a.m.
On 2023-04-11 03:04, Thomas DeBellis wrote:
Yes, I was catching up on that, but perhaps not
keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of
PyDECnet, but anyway, that detail will improve soon.
So what's the bottom line here? Is netpth rolling
over and dying
actually legitimate or is there a better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is
also unclear. Maybe it has a more rigid idea on how circuit names should
look? PyDECnet allows pretty much anything as a circuit name. DEC was a
bit more conservative... I think you need to dig around on that maybe.
Johnny
On 4/10/23 9:00 PM, Johnny Billquist wrote:
--
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
That's what the thread between me and Paul
right now is about. And
Paul have this fixed in his code now. Next version should have it fixed.
Johnny
On 2023-04-11 02:54, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se I don't have an informed opinion yet, as I
only just started
looking. The code is kind of odd in that it is half Tops-10 andhalf
Tops-20, but not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct. Now,
if I just look at the show node /xxx/status, I was wondering about
something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
Obviously, there is no good reason to ask for the
circuit
information. You already got all you needed from the show node xx
status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
> It sits in a loop doing the following:
>
> show node xxx:: status
>
> From that it picks out the appropriate circuit and does a
>
> show circuit xxx status
>
> So, to show the path from venti2:: to twenex::, the first few
> commands would be
>
> NCP>*shoW noDE twenex:: statUS *
>
> Remote Node = 31.29 (TWENEX)
>
> Active Links = 0
> Delay = 1
>
> Circuit = NI-0-0
> Next Node = 2.1023 (A2RTR)
> NCP>*shoW cirCUIT ni-0-0 staTUS *
>
> Circuit State Loopback Adjacent Block
> Name Node Size
> NI-0-0 On 2.1023 (A2RTR) 591
> Designated Router = 2.1023 (A2RTR)
> NI-0-0 2.520 (TOMMYT) 1476
> NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
>
> Remote Node = 31.29 (TWENEX)
>
>
> Circuit = DMC-31
> Next Node = 31.3 (PYRTR)
> NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
>
> Circuit = DMC-31
>
> State = On
>
> Adjacent Node = 31.3 (PYRTR)
> Block Size = 576
> NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
>
> Remote Node = 31.29 (TWENEX)
>
> State = Reachable
> Delay = 1
> Cost = 24
> Hops = 2
>
> Circuit = MUL-31-32
> NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
> *
> Circuit = MUL-31-32
>
> Adjacent Node = 31.32 (PIPY)
> Block Size = 576
> State = On
> NCP>*telL pipy:: shOW noDE twenex:: statUS **
> *
> Remote Node = 31.29 (TWENEX)
>
> State = Reachable
> Type = Nonrouting IV
> Cost = 4
> Hops = 1
>
> Circuit = VDE-31
> NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
>
> Circuit = VDE-31
>
> Adjacent Node = 31.1022 (AHIMSA)
> Block Size = 591
> State = On
>
> Adjacent Node = 31.1020 (MOKSHA)
> Block Size = 591
>
> Adjacent Node = 31.13 (FEDACH)
> Block Size = 1498
>
> Adjacent Node = 31.19 (MACOS9)
> Block Size = 1498
>
> Adjacent Node = 31.14 (FOMFOR)
> Block Size = 1498
>
> Adjacent Node = 31.26 (W2000S)
> Block Size = 1498
>
> Adjacent Node = 31.18 (RAPTOR)
> Block Size = 1498
>
> Adjacent Node = 31.21 (WXPEE2)
> Block Size = 1498
>
> Adjacent Node = 31.22 (TRU64)
> Block Size = 1490
>
> Adjacent Node = 31.20 (WFW311)
> Block Size = 1498
>
> Adjacent Node = 31.16 (WEXPEE)
> Block Size = 1498
>
> Adjacent Node = 31.11 (CLOUDY)
> Block Size = 1498
>
> Adjacent Node = 31.10 (QCOCAL)
> Block Size = 1498
>
> Adjacent Node = 31.12 (JUICHI)
> Block Size = 576
>
> Adjacent Node = 31.23 (XLVII)
> Block Size = 1498
>
> Adjacent Node = 31.24 (TSTVAX)
> Block Size = 1498
>
> Adjacent Node = 31.28 (RST101)
> Block Size = 598
>
> Adjacent Node = 31.31 (XLIV)
> Block Size = 1498
>
> Adjacent Node = 31.33 (XL)
> Block Size = 1498
>
> Adjacent Node = 31.34 (NANAJU)
> Block Size = 576
>
> Adjacent Node = 31.35 (NJEVX1)
> Block Size = 1498
>
> Adjacent Node = 31.36 (NJEVX2)
> Block Size = 1498
>
> Adjacent Node = 31.41 (KDJ11E)
> Block Size = 576
>
> Adjacent Node = 31.44 (XLVI)
> Block Size = 1498
>
> Adjacent Node = 31.39 (ROUT20)
> Block Size = 1498
>
> Adjacent Node = 31.38 (LV)
> Block Size = 1498
>
> Adjacent Node = 31.15 (OSTARA)
> Block Size = 1498
>
> Adjacent Node = 31.30 (VAXSTN)
> Block Size = 1498
>
> Adjacent Node = 31.42 (XXXV)
> Block Size = 1498
>
> Adjacent Node = 31.1021 (PYDNET)
> Block Size = 591
>
> Adjacent Node = 31.27 (MACOS7)
> Block Size = 1498
>
> /Adjacent Node = 31.29 (//TWENEX//)//
> // Block Size = 576/
>
>
>
> ------------------------------------------------------------------------
>
>
> On 4/10/23 6:30 PM, Johnny Billquist wrote:
>> Could you tell in detail which NICE messages you are generating?
>>
>> In general, if I were to do such a tool, I would normally do the
>> NICE message that generates the same request as NCP SHO NOD do.
>>
>> To give an example from JOCKE to A2RTR:
>>
>> .ncp sho nod a2rtr
>>
>> Node summary as of 11-APR-23 00:26:52
>>
>> Remote Active Next
>> Node State Links Delay Circuit Node
>>
>> 2.1023 (A2RTR) 1.15 (PONDUS)
>>
>> .ncp tell pondus sho nod a2rtr
>>
>> Node summary as of 11-APR-23 00:27:05
>>
>> Remote Active Next
>> Node State Links Delay Circuit Node
>>
>> 2.1023 (A2RTR) 1.13 (MIM)
>>
>> .ncp tell mim sho nod a2rtr
>>
>> Node summary as of 11-APR-23 00:27:21
>>
>> Remote Active Next
>> Node State Links Delay Circuit Node
>>
>> 2.1023 (A2RTR) 31.3 (PYRTR)
>>
>> .ncp tell pyrtr sho nod a2rtr
>>
>> Node summary as of 11-APR-23 00:27:30
>>
>> Remote Active Next
>> Node State Links Delay Circuit Node
>>
>> 2.1023 (A2RTR)
>>
>>
>>
>> Sadly PYRTR did not actually tell what the next node is here. Not
>> sure if it's just an old version of PYRTR, or if there is
>> something for Paul to improve. But you should get the idea...
>>
>> Also, note that this will give the forward path, which in DECnet
>> most certainly might be different than the return path...
>>
>> Johnny
>>
>>
>> On 2023-04-10 23:58, Thomas DeBellis wrote:
>>> Now that I'm done with Kermit-20, I wanted to get back to
>>> finishing up some other work that I had been doing. FAL, DAP and
>>> NFT are in good enough shape for me to leave them alone for the
>>> moment, so that's another rabbit hole I've gotten myself out of.
>>>
>>> I'm now looking fix an error that I somehow introduced into
>>> MMAILR (SMTP over DECnet). Fixing this required modifying DDT,
>>> whichIhad to do to fix another issue I had introduced into
>>> Kermit. I wanted to have a quick look at what Tops-20 hosts
>>> might be up on HECnet and wrote up a little batch job to use
>>> NETPTH to test connectivity.
>>>
>>> NETPTH is a nifty utility to find paths between DECnet nodes. It
>>> builds a connection the NCU's of various nodes to determine the
>>> path that a message might take to get there. Think of it like
>>> traceroute or ping -R (RECORD_ROUTE option).
>>>
>>> It almost never works...
>>>
>>> Before I roll up my sleeves and jump into this I was wondering if
>>> anybody had any observations about the errors I'm seeing?
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>> A2RTR (2.1023) =>DMC-31 /
>>> ?NETCFO Can't find Output Circuit parameter
>>>
>>> *SAMT20*::
>>> ?NETURN Unreachable node
>>>
>>> *TOMMYT*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520) 1 1
>>>
>>> *BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>> A2RTR (2.1023) =>
>>> ?NETCFO Can't find Output Circuit parameter
>>>
>>> *WALACH*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>> A2RTR (2.1023) =>DMC-29-206 /
>>> ?NETCFO Can't find Output Circuit parameter
>>>
>>> *SOL*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>>> -1 -1
>>> STORTR (59.1016) =>GRE-16 /
>>> ?NETCFO Can't find Output Circuit parameter
>>>
>>> *FENCER*::
>>>
>>> From Via Back Thru Cost Hops
>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>>> -1 -1
>>> STORTR (59.1016) =>GRE-16 /
>>> ?NETPTH NTMAN failed, reason:
>>> Parameter missing
>>> $
>>>
>>>
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
2:38 p.m.
On Apr 10, 2023, at 9:09 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
PyDECnet is trying to follow the DECnet architecture specs closely (even to the point of
being struturally similar, something other implementations tend not to do).
Yes, I was catching up on that, but perhaps not
keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but
anyway, that detail will improve soon. So what's
the bottom line here? Is netpth rolling over and dying actually legitimate or is there a
better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is also unclear.
Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty
much anything as a circuit name. DEC was a bit more conservative... I think you need to
dig around on that maybe.
4:31 p.m.
On 2023-04-11 14:38, Paul Koning wrote:
I always thought of circuit names as more or less a suggestion, and certainly seeing
circuit names in Phase II reinforced that. The specs have them as ASCII strings, no
constraints (though TOPS-20 Phase II is severely constrained by implementation choice).
So the way to deal with circuit names is just that, as ASCII strings subject to the length
limit in the spec but not otherwise constrained.
In at least RSX, they are not just random, format free strings.
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify
things, and parts can be wildcarded.
For example, ethernet controllers have names like UNA-0, UNA-1 and so
on. Basically the controller (driver) name, followed by a number telling
which controller it is.
DDCMP lines have a form like DZ-0-0, which is DZ controller #0, line #0.
So you can also see DZ-1-7, for example.
Then you have multidrop lines, which have the form DZ-0-0.0, which is
controller 0, line 0, tributary 0.
My IP device have just one controller always, but can have multiple
lines. And you can set all circuits off with the command
NCP SET CIR IP-0-* STA OFF
for which NCP understand how to wildcard. And it's not just a simple
string wildcarding. Observe:
.ncp sho cir ip-0-*
Circuit summary as of 11-APR-23 16:29:24
Circuit = IP-0-0
State = On-starting
Circuit = IP-0-1
State = On
Adjacent node = 31.3 (PYRTR)
Circuit = IP-0-2
State = On
Adjacent node = 59.55 (KRYLBO)
Circuit = IP-0-3
State = On
Adjacent node = 1.15 (PONDUS)
Circuit = IP-0-4
State = On
Adjacent node = 1.860 (ER01RX)
Circuit = IP-0-5
State = On
Adjacent node = 29.2 (A29RT2)
Circuit = IP-0-6
State = On
Adjacent node = 1.840 (OLOF00)
Circuit = IP-0-7
State = On
Adjacent node = 62.637 (CTAKAH)
.ncp sho cir ip-*
NCP -- Show failed, invalid identification format, Circuit
And in RSX, all devices are max 3 characters. Same with VMS, if I
remember right. I have not checked if RSX might have some opinion of
it's more than 3 characters. But I have no idea what NETPTH might be
doing with circuit names, or how it process them, and if the problem is
there. I was just trying to guess based on some of the error messages
what it *might* be. :-)
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
On Apr 10, 2023, at 9:09 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
PyDECnet is trying to follow the DECnet architecture specs closely (even to the point of
being struturally similar, something other implementations tend not to do).
Yes, I was catching up on that, but perhaps not
keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but
anyway, that detail will improve soon. So
what's the bottom line here? Is netpth rolling over and dying actually legitimate or
is there a better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is also unclear.
Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty
much anything as a circuit name. DEC was a bit more conservative... I think you need to
dig around on that maybe.
4:42 p.m.
On Apr 11, 2023, at 10:31 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 14:38, Paul Koning wrote:
I always thought of circuit names as more or less a
suggestion, and certainly seeing circuit names in Phase II reinforced that. The specs
have them as ASCII strings, no constraints (though TOPS-20 Phase II is severely
constrained by implementation choice). So the way to deal with circuit names is just
that, as ASCII strings subject to the length limit in the spec but not otherwise
constrained.
In at least RSX, they are not just random, format free strings.
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify things, and parts can
be wildcarded.
Indeed, for any given implementation there are patterns and they are followed
semi-consistently across implementations. But the architecture spec has no rules other
than that circuit and line names are "id-string". The only place I see the
dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device".
Also, even when an implementation follows the RSX pattern, the actual names used may vary.
For example, async DDCMP on RSTS uses circuit names of the form TT-# no matter what
controller type is involved.
It gets worse when you consider Phase II, where circuit names contain underscores rather
than hyphens. So for an application that reads circuit and node info from other
implementations, the rule I would suggest is to assume nothing about the structure of
circuit names.
paul
On Apr
10, 2023, at 9:09 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
PyDECnet is trying to follow the DECnet
architecture specs closely (even to the point of being struturally similar, something
other implementations tend not to do).
Yes, I was catching up on that, but perhaps not
keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but
anyway, that detail will improve soon. So
what's the bottom line here? Is netpth rolling over and dying actually legitimate or
is there a better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is also unclear.
Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty
much anything as a circuit name. DEC was a bit more conservative... I think you need to
dig around on that maybe.
5:14 p.m.
On 2023-04-11 16:42, Paul Koning wrote:
Well, controllers like ethernet usually are in the form dev-#. They
don't have multiple lines in the way a serial controller do.
On Apr 11, 2023, at 10:31 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 14:38, Paul Koning wrote:
In at least RSX, they are not just random, format free strings.
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify things, and parts can
be wildcarded.
Indeed, for any given implementation there are patterns and they are followed
semi-consistently across implementations. But the architecture spec has no rules other
than that circuit and line names are "id-string". The only place I see the
dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device". On Apr
10, 2023, at 9:09 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
> Yes, I was catching up on that, but perhaps not keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but
anyway, that detail will improve soon.
PyDECnet is trying to follow the DECnet
architecture specs closely (even to the point of being struturally similar, something
other implementations tend not to do).
> So what's the bottom line here? Is
netpth rolling over and dying actually legitimate or is there a better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is also unclear.
Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty
much anything as a circuit name. DEC was a bit more conservative... I think you need to
dig around on that maybe.
I always thought of circuit names as more or less a
suggestion, and certainly seeing circuit names in Phase II reinforced that. The specs
have them as ASCII strings, no constraints (though TOPS-20 Phase II is severely
constrained by implementation choice). So the way to deal with circuit names is just
that, as ASCII strings subject to the length limit in the spec but not otherwise
constrained. Also, even when an implementation follows the RSX
pattern, the actual names used may vary. For example, async DDCMP on RSTS uses circuit
names of the form TT-# no matter what controller type is involved.
Oh. I was definitely not trying to imply that there are any specific
names used on the dev part. That is clearly a string that might be
whatever. It might possibly have some length limit, and I don't think
anything but letters are allowed. But that's about it.
It gets worse when you consider Phase II, where
circuit names contain underscores rather than hyphens. So for an application that reads
circuit and node info from other implementations, the rule I would suggest is to assume
nothing about the structure of circuit names.
Underscores might be an interesting thing to investigate. But I'm not
going down that rabbit hole right now.
I'm merely suggesting that maybe NETPTH, or TOPS might have some
additional constraints on circuit names, which is why Thomas got some of
his errors...
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
7:51 p.m.
On Apr 11, 2023, at 11:14 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 16:42, Paul Koning wrote:
Well, controllers like ethernet usually are in the form dev-#. They don't have
multiple lines in the way a serial controller do.
The network management architecture spec says:
" ...id-string
consists of one to sixteen characters from the set of upper-case
alphabetics, numerics, period and hyphen. An id-string must contain
at least one alphabetic character."
Most names, including circuit, line, and module names are "id-string".
On Apr
11, 2023, at 10:31 AM, Johnny Billquist <bqt(a)softjar.se> wrote:
...
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify things, and parts can
be wildcarded.
Indeed, for any given implementation there are patterns and they are
followed semi-consistently across implementations. But the architecture spec has no rules
other than that circuit and line names are "id-string". The only place I see
the dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device". Also, even when an implementation follows the RSX
pattern, the actual names used may vary. For example, async DDCMP on RSTS uses circuit
names of the form TT-# no matter what controller type is involved.
Oh. I was definitely not trying to imply that there are any specific names used on the
dev part. That is clearly a string that might be whatever. It might possibly have some
length limit, and I don't think anything but letters are allowed. But that's about
it. It gets worse
when you consider Phase II, where circuit names contain underscores rather than hyphens.
So for an application that reads circuit and node info from other implementations, the
rule I would suggest is to assume nothing about the structure of circuit names.
Underscores might be an interesting thing to investigate. But I'm not going down that
rabbit hole right now.
8:10 p.m.
At least for what would be a typical hobby configuration for a KL based
system, Tops-20 doesn't care how specific you get, NI-0 and NI-0-0
basically getting you the same thing, viz:
NCP>show liNE ni-0 13:53:29 NCP Request # 1104; Show Line
Summary Completed Line = NI-0 State = On NCP>show line ni-0-0
13:53:37 NCP Request # 1105; Show Line Summary Completed Line =
NI-0-0 State = On NCP>
I think what would really be necessary to know would be to have access
to a connected (PDP-11 based) DN20 (running MCB), which is where actual
DDCMP lines would be found. The DTE interface on KLH10 does not
simulate this, but I think some work may have been done as a Chaosnet
implementation appears to be simulating what MIT did, repurpose a DN20
with special code, the Ethernet adapter being in the DN20.
What I recall is that you needed the final /-x/ for lines or controllers
that could handle multiple lines. I believe a KMC would do that, but I
honestly don't remember.
The source for Tops-20/Tops-10 Phase IV NICE is written in BLISS, so I
don't know how finicky it would be about what's in the string.
I keep daydreaming about taking the Phase II NICE, which I do have, and
updating it for Phase IV. This would be a lot of work, so I haven't
really looked into the matter. If I did, then I would use full COMND%
parsing to get recognition on the line types, DMR, NI, CI, KMC, Etc.
That might be a fantasy as I would imagine these were never standardized.
In that case, I could parse for either a dash or underscore as a
separator in the event of talking to a Phase II node. If I had
awareness of what was running, then the parse options can be changed on
the fly. I do this all over the place in other programs and it's really
nice to have a program tell you what it's expecting based on the actual
environment instead of what's possible.
For example, for the executor node, I could issue a SHOW KNOWN LINES and
parse that for the line type prefixes and have awareness for that node,
allowing escape recognition.
I do think being able to wildcard and match lines like what RSX does
would be a fine feature. Another thing that makes me want to roll up my
sleeves and dive into a NICE rewrite.
------------------------------------------------------------------------
On 4/11/23 1:51 PM, Paul Koning wrote:
Phase II NICE has two different
encodings for line names: ASCII string which seems to be pretty much unconstrained, and a
compact coded form consisting of a device code, controller number, and optional line
number. TOPS-20 only implements the latter, it seems. And the text representation shown
for that second form is dev_# for line 0, dev_#_# for non-zero line numbers. There is a
short list of defined device codes, so if a node wants to tell TOPS-20 that it has a line
named ETH-0, it can't do that.
paul
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
On Apr 11, 2023, at 11:14 AM, Johnny
Billquist<bqt(a)softjar.se> wrote:
On 2023-04-11 16:42, Paul Koning wrote:
Well, controllers like ethernet usually are in the
form dev-#. They don't have multiple lines in the way a serial controller do.
The network management architecture spec says:
" ...id-string
consists of one to sixteen characters from the set of upper-case
alphabetics, numerics, period and hyphen. An id-string must contain
at least one alphabetic character."
Most names, including circuit, line, and module names are "id-string".
On Apr
11, 2023, at 10:31 AM, Johnny Billquist<bqt(a)softjar.se> wrote:
...
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify things, and parts can
be wildcarded.
Indeed, for any given implementation there are patterns and they are
followed semi-consistently across implementations. But the architecture spec has no rules
other than that circuit and line names are "id-string". The only place I see
the dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device". Also, even when an implementation follows the RSX
pattern, the actual names used may vary. For example, async DDCMP on RSTS uses circuit
names of the form TT-# no matter what controller type is involved.
Oh. I was
definitely not trying to imply that there are any specific names used on the dev part.
That is clearly a string that might be whatever. It might possibly have some length limit,
and I don't think anything but letters are allowed. But that's about it. It gets
worse when you consider Phase II, where circuit names contain underscores rather than
hyphens. So for an application that reads circuit and node info from other
implementations, the rule I would suggest is to assume nothing about the structure of
circuit names.
Underscores might be an interesting thing to investigate. But
I'm not going down that rabbit hole right now.
8:16 p.m.
On Apr 11, 2023, at 2:10 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
...
I keep daydreaming about taking the Phase II NICE, which I do have, and updating it for
Phase IV. This would be a lot of work, so I haven't really looked into the matter.
If I did, then I would use full COMND% parsing to get recognition on the line types, DMR,
NI, CI, KMC, Etc. That might be a fantasy as I would imagine these were never
standardized.
Perhaps the simplest fix would be to allow ASCII string format line names. The current
code only accepts the compact binary format, and then only a few device names of the list
(DMC, DUP, DTE, and KDP).
paul
9:12 p.m.
Note that for line names, there is no standard, because it's really up
to each OS how they might name them.
In RSX, ethernet would be UNA or QNA (or CNA on a Pro). But on VMS, you
then continued with all kind of names depending on what ethernet
controller/chip was used on that hardware.
I seem to remember EZA for example.
And of course, on a KL the ethernet is NIA-20, but I seem to remember
that the name in DECnet was just NI. So any parsing really either needs
to reach out to the node to find what was used on that one, or else, it
really is any string is acceptable.
But with that said, RSX do consider the dash to be a separator and you
can wildcard things in certain ways beyond that.
Johnny
On 2023-04-11 20:10, Thomas DeBellis wrote:
At least for what would be a typical hobby
configuration for a KL based
system, Tops-20 doesn't care how specific you get, NI-0 and NI-0-0
basically getting you the same thing, viz:
NCP>show liNE ni-0 13:53:29 NCP Request # 1104; Show Line
Summary Completed Line = NI-0 State = On NCP>show line ni-0-0
13:53:37 NCP Request # 1105; Show Line Summary Completed Line =
NI-0-0 State = On NCP>
I think what would really be necessary to know would be to have access
to a connected (PDP-11 based) DN20 (running MCB), which is where actual
DDCMP lines would be found. The DTE interface on KLH10 does not
simulate this, but I think some work may have been done as a Chaosnet
implementation appears to be simulating what MIT did, repurpose a DN20
with special code, the Ethernet adapter being in the DN20.
What I recall is that you needed the final /-x/ for lines or controllers
that could handle multiple lines. I believe a KMC would do that, but I
honestly don't remember.
The source for Tops-20/Tops-10 Phase IV NICE is written in BLISS, so I
don't know how finicky it would be about what's in the string.
I keep daydreaming about taking the Phase II NICE, which I do have, and
updating it for Phase IV. This would be a lot of work, so I haven't
really looked into the matter. If I did, then I would use full COMND%
parsing to get recognition on the line types, DMR, NI, CI, KMC, Etc.
That might be a fantasy as I would imagine these were never standardized.
In that case, I could parse for either a dash or underscore as a
separator in the event of talking to a Phase II node. If I had
awareness of what was running, then the parse options can be changed on
the fly. I do this all over the place in other programs and it's really
nice to have a program tell you what it's expecting based on the actual
environment instead of what's possible.
For example, for the executor node, I could issue a SHOW KNOWN LINES and
parse that for the line type prefixes and have awareness for that node,
allowing escape recognition.
I do think being able to wildcard and match lines like what RSX does
would be a fine feature. Another thing that makes me want to rollup my
sleeves and dive into a NICE rewrite.
--
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
------------------------------------------------------------------------
On 4/11/23 1:51 PM, Paul Koning wrote:
Phase II NICE has two different
encodings for line names: ASCII stringwhich seems to be pretty much unconstrained, and a
compact coded form consisting of a device code, controller number, and optional line
number. TOPS-20 only implements the latter, it seems. And the text representation shown
for that second form is dev_# for line 0, dev_#_# for non-zero line numbers. There is a
short list of defined device codes, so if a node wants to tell TOPS-20 that it has a line
named ETH-0, it can't do that.
paul
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Apr 11, 2023, at 11:14 AM, Johnny
Billquist<bqt(a)softjar.se> wrote:
On 2023-04-11 16:42, Paul Koning wrote:
The network management architecture spec says:
" ...id-string
consists of one to sixteen characters from the set of upper-case
alphabetics, numerics, period and hyphen. An id-string must contain
at least one alphabetic character."
Most names, including circuit, line, and module names are "id-string".
> On Apr 11, 2023, at 10:31 AM, Johnny
Billquist<bqt(a)softjar.se> wrote:
> ...
> They are in the form dev-#, dev-#-# or dev-#-#.#. All which signifythings, and parts
can be wildcarded.
Indeed, for any given implementation there are patterns and they arefollowed
semi-consistently across implementations. But the architecturespec has no rules other
than that circuit and line names are "id-string". The only place I see the
dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device".
Well, controllers like ethernet usually are in the
form dev-#. They don't have multiple lines in the way a serial controller do.
Also, even when an implementation follows the RSX
pattern, the actual names used may vary. For example, async DDCMP on RSTS uses circuit
names of the form TT-# no matter what controller type is involved.
Oh. I was
definitely not trying to imply that there are any specific names used on the dev part.
That is clearly a string that might be whatever. It might possibly have some length limit,
and I don't think anything but letters are allowed. But that's about it. It gets
worse when you consider Phase II, where circuit names contain underscores rather than
hyphens. So for an application that reads circuit and node info from other
implementations, the rule I would suggest isto assume nothing about the structure of
circuit names.
Underscores might be an interesting thing to investigate. But
I'm notgoing down that rabbit hole right now.
7 p.m.
Regarding its performance, I don't think netpth was ever a candidate for
full productization, apparently being more of an internal tool for
DECnet specialists. However, this is only a guess.
From the edit history, it looks like it started out life in 1982 being
put together by Stu Grossman, who I thought was working on Stanford at
the time. That would be surprising as I had thought Stanford didn't run
Tops-10. But maybe I'm wrong on both counts. It then appears to have
been adopted by Bill Davenport, Gunnar Lindell and Carl Appellof. I
don't know about Bill or Gunnar, but I'm pretty sure I remember Carl
being at DEC.
I would guess netpth was part of a Tops-10 SWSKIT and was then partially
ported to Tops-20. It only uses those Tops-20 JSYi that are necessary
to do its job. Since Phase IV DECnet on the PDP-10 was first developed
under Tops-10 (where it could run in user mode) and then ported to
Tops-20 (it's all under conditional assembly), the API's are remarkably
similar. What I mean by that is the Tops-10 UUO and Tops-20 JSYS
calling interface are nearly plug compatible with the exception of the
UUO having more flexible register scheduling.
So, I think the crashing is due to error conditions that weren't
anticipated in those early days, that is, that you would never /not/ get
told what the adjacent nodes were. It is also not impossible that some
of the fixes that I put into Tops-20 to report secondary error
conditions could be triggering this.
I do remember netpth working at some point, Peter Lothberg demonstrated
it about a year and a half ago on 10/21/21, viz:
[Routing path from MRC (59.41) to LEGATO (2.1)] From Via Back Thru
Cost Hops MRC (59.41) =>NI-0-0 / TAP-0 <= OPS1VA (59.59) -1 -1
OPS1VA (59.59) =>GRE-3 / GRE-4 <= IAD2 (59.1020) -1 -1 IAD2
(59.1020) =>DMC-0 / MUL-59-1020 <= A2RTR (2.1023) -1 -1 A2RTR
(2.1023) =>TAP-0 / QNA-1 <= LEGATO (2.1) -1 -1
I ran a few tests looking for various PyDECnet versions and their
responses to a SHOW NODE /xxx/:: STATUS, viz:
*Node*
*PyDECnet Version*
*Next Node?*
A2RTR::
V1.0-596
Yes
PYRTR::
T1.1-640
No
STORTR::
/*** Not Reported ***/
Yes (Numeric, Only)
DEC000::
V1.0-583
No
NOVA::
V1.0-596
Yes
A29RT2::
T1.1-648
No
This suggested running a test through the older versions, which
*worked*, viz:
[Routing path from VENTI2 (2.522) to SAMV02 (2.152)] From Via Back
Thru Cost Hops VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) 10
3 A2RTR (2.1023) =>MUL-2-150 / MUL-1 <= SAMISH (2.199) 9 2 SAMISH
(2.199) =>ETH-0 / UNA-0 <= SAMV02 (2.152) 4 1
So what is this? A newer version of PyDECnet isn't 'doing the right thing'?
netpth should probably have some more robust error recovery. Doing the
same thing for SAMT20:: got me almost the same thing except when netpth
got to the last part, it died with:
?NETPTH Connection rejected, reason: Reject or disconnect by object
So that's something to look at. Also, although this shouldn't matter,
I'm not sure if SAMT20:: is in a funny state or is perhaps
misdocumented. A connection attempt with the _just released_ Kermit-20
shows:
Kermit-20>*connect samt20:: /stay* % Kermit-20: Can't enable ^C
capability--use ^G instead [Remote system SAMT20:: is running VMS]
?SAMT20:: does not support Tops-10/Tops-20 Network Remote Terminal
protocol Kermit-20>
Again, as per Paul's recommendation, Kermit-20 only reports the remote
operating system, it makes its connection decision based on which NRT
transports the remote node offers.
------------------------------------------------------------------------
On 4/10/23 9:09 PM, Johnny Billquist wrote:
------------------------------------------------------------------------
On 2023-04-11 03:04, Thomas DeBellis wrote:
Yes, I was catching up on that, but perhaps not keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior
of PyDECnet, but anyway, that detail will improve soon.
So what's the bottom line here? Is netpth
rolling over and dying
actually legitimate or is there a better algorithm to use?
I don't think there
any better algorithm. Why netpth throws errors is
also unclear. Maybe it has a more rigid idea on how circuit names
should look? PyDECnet allows pretty much anything as a circuit name.
DEC was a bit more conservative... I think you need to dig around on
that maybe.
Johnny
------------------------------------------------------------------------
On 4/10/23 9:00 PM, Johnny Billquist wrote:
That's what the thread between me and Paul right now is about. And
Paul have this fixed in his code now. Next
version should have it fixed.
Johnny
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
------------------------------------------------------------------------
On 2023-04-11 02:54, Thomas DeBellis wrote:
I don't have an informed opinion yet, as I only just started
looking. The code is kind of odd in that it is half Tops-10
andhalf Tops-20, but not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct.
Now, if I just look at the show node /xxx/status, I was wondering
about something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
> Obviously, there is no good reason to ask for the circuit
> information. You already got all you needed from the show node xx
> status, right?
>
> Johnny
>
> On 2023-04-11 02:37, Thomas DeBellis wrote:
>> It sits in a loop doing the following:
>>
>> show node xxx:: status
>>
>> From that it picks out the appropriate circuit and does a
>>
>> show circuit xxx status
>>
>> So, to show the path from venti2:: to twenex::, the first few
>> commands would be
>>
>> NCP>*shoW noDE twenex:: statUS *
>>
>> Remote Node = 31.29 (TWENEX)
>>
>> Active Links = 0
>> Delay = 1
>>
>> Circuit = NI-0-0
>> Next Node = 2.1023 (A2RTR)
>> NCP>*shoW cirCUIT ni-0-0 staTUS *
>>
>> Circuit State Loopback Adjacent Block
>> Name Node Size
>> NI-0-0 On 2.1023 (A2RTR) 591
>> Designated Router = 2.1023 (A2RTR)
>> NI-0-0 2.520 (TOMMYT) 1476
>> NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
>>
>> Remote Node = 31.29 (TWENEX)
>>
>>
>> Circuit = DMC-31
>> Next Node = 31.3 (PYRTR)
>> NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
>>
>> Circuit = DMC-31
>>
>> State = On
>>
>> Adjacent Node = 31.3 (PYRTR)
>> Block Size = 576
>> NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
>>
>> Remote Node = 31.29 (TWENEX)
>>
>> State = Reachable
>> Delay = 1
>> Cost = 24
>> Hops = 2
>>
>> Circuit = MUL-31-32
>> NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
>> *
>> Circuit = MUL-31-32
>>
>> Adjacent Node = 31.32 (PIPY)
>> Block Size = 576
>> State = On
>> NCP>*telL pipy:: shOW noDE twenex:: statUS **
>> *
>> Remote Node = 31.29 (TWENEX)
>>
>> State = Reachable
>> Type = Nonrouting IV
>> Cost = 4
>> Hops = 1
>>
>> Circuit = VDE-31
>> NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
>>
>> Circuit = VDE-31
>>
>> Adjacent Node = 31.1022 (AHIMSA)
>> Block Size = 591
>> State = On
>>
>> Adjacent Node = 31.1020 (MOKSHA)
>> Block Size = 591
>>
>> Adjacent Node = 31.13 (FEDACH)
>> Block Size = 1498
>>
>> Adjacent Node = 31.19 (MACOS9)
>> Block Size = 1498
>>
>> Adjacent Node = 31.14 (FOMFOR)
>> Block Size = 1498
>>
>> Adjacent Node = 31.26 (W2000S)
>> Block Size = 1498
>>
>> Adjacent Node = 31.18 (RAPTOR)
>> Block Size = 1498
>>
>> Adjacent Node = 31.21 (WXPEE2)
>> Block Size = 1498
>>
>> Adjacent Node = 31.22 (TRU64)
>> Block Size = 1490
>>
>> Adjacent Node = 31.20 (WFW311)
>> Block Size = 1498
>>
>> Adjacent Node = 31.16 (WEXPEE)
>> Block Size = 1498
>>
>> Adjacent Node = 31.11 (CLOUDY)
>> Block Size = 1498
>>
>> Adjacent Node = 31.10 (QCOCAL)
>> Block Size = 1498
>>
>> Adjacent Node = 31.12 (JUICHI)
>> Block Size = 576
>>
>> Adjacent Node = 31.23 (XLVII)
>> Block Size = 1498
>>
>> Adjacent Node = 31.24 (TSTVAX)
>> Block Size = 1498
>>
>> Adjacent Node = 31.28 (RST101)
>> Block Size = 598
>>
>> Adjacent Node = 31.31 (XLIV)
>> Block Size = 1498
>>
>> Adjacent Node = 31.33 (XL)
>> Block Size = 1498
>>
>> Adjacent Node = 31.34 (NANAJU)
>> Block Size = 576
>>
>> Adjacent Node = 31.35 (NJEVX1)
>> Block Size = 1498
>>
>> Adjacent Node = 31.36 (NJEVX2)
>> Block Size = 1498
>>
>> Adjacent Node = 31.41 (KDJ11E)
>> Block Size = 576
>>
>> Adjacent Node = 31.44 (XLVI)
>> Block Size = 1498
>>
>> Adjacent Node = 31.39 (ROUT20)
>> Block Size = 1498
>>
>> Adjacent Node = 31.38 (LV)
>> Block Size = 1498
>>
>> Adjacent Node = 31.15 (OSTARA)
>> Block Size = 1498
>>
>> Adjacent Node = 31.30 (VAXSTN)
>> Block Size = 1498
>>
>> Adjacent Node = 31.42 (XXXV)
>> Block Size = 1498
>>
>> Adjacent Node = 31.1021 (PYDNET)
>> Block Size = 591
>>
>> Adjacent Node = 31.27 (MACOS7)
>> Block Size = 1498
>>
>> /Adjacent Node = 31.29 (//TWENEX//)//
>> // Block Size = 576/
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> On 4/10/23 6:30 PM, Johnny Billquist wrote:
>>> Could you tell in detail which NICE messages you are generating?
>>>
>>> In general, if I were to do such a tool, I would normally do the
>>> NICE message that generates the same request as NCP SHO NOD do.
>>>
>>> To give an example from JOCKE to A2RTR:
>>>
>>> .ncp sho nod a2rtr
>>>
>>> Node summary as of 11-APR-23 00:26:52
>>>
>>> Remote Active Next
>>> Node State Links Delay Circuit Node
>>>
>>> 2.1023 (A2RTR) 1.15 (PONDUS)
>>>
>>> .ncp tell pondus sho nod a2rtr
>>>
>>> Node summary as of 11-APR-23 00:27:05
>>>
>>> Remote Active Next
>>> Node State Links Delay Circuit Node
>>>
>>> 2.1023 (A2RTR) 1.13 (MIM)
>>>
>>> .ncp tell mim sho nod a2rtr
>>>
>>> Node summary as of 11-APR-23 00:27:21
>>>
>>> Remote Active Next
>>> Node State Links Delay Circuit Node
>>>
>>> 2.1023 (A2RTR) 31.3 (PYRTR)
>>>
>>> .ncp tell pyrtr sho nod a2rtr
>>>
>>> Node summary as of 11-APR-23 00:27:30
>>>
>>> Remote Active Next
>>> Node State Links Delay Circuit Node
>>>
>>> 2.1023 (A2RTR)
>>>
>>>
>>>
>>> Sadly PYRTR did not actually tell what the next node is here.
>>> Not sure if it's just an old version of PYRTR, or if there is
>>> something for Paul to improve. But you should get the idea...
>>>
>>> Also, note that this will give the forward path, which in DECnet
>>> most certainly might be different than the return path...
>>>
>>> Johnny
>>>
>>>
>>> On 2023-04-10 23:58, Thomas DeBellis wrote:
>>>> Now that I'm done with Kermit-20, I wanted to get back to
>>>> finishing up some other work that I had been doing. FAL, DAP
>>>> and NFT are in good enough shape for me to leave them alone for
>>>> the moment, so that's another rabbit hole I've gotten myself
>>>> out of.
>>>>
>>>> I'm now looking fix an error that I somehow introduced into
>>>> MMAILR (SMTP over DECnet). Fixing this required modifying DDT,
>>>> whichIhad to do to fix another issue I had introduced into
>>>> Kermit. I wanted to have a quick look at what Tops-20 hosts
>>>> might be up on HECnet and wrote up a little batch job to use
>>>> NETPTH to test connectivity.
>>>>
>>>> NETPTH is a nifty utility to find paths between DECnet nodes.
>>>> It builds a connection the NCU's of various nodes to determine
>>>> the path that a message might take to get there. Think of it
>>>> like traceroute or ping -R (RECORD_ROUTE option).
>>>>
>>>> It almost never works...
>>>>
>>>> Before I roll up my sleeves and jump into this I was wondering
>>>> if anybody had any observations about the errors I'm seeing?
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
>>>>
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>>>> -1 -1
>>>> A2RTR (2.1023) =>DMC-31 /
>>>> ?NETCFO Can't find Output Circuit parameter
>>>>
>>>> *SAMT20*::
>>>> ?NETURN Unreachable node
>>>>
>>>> *TOMMYT*::
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520) 1 1
>>>>
>>>> *BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>>> A2RTR (2.1023) =>
>>>> ?NETCFO Can't find Output Circuit parameter
>>>>
>>>> *WALACH*::
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023)
>>>> -1 -1
>>>> A2RTR (2.1023) =>DMC-29-206 /
>>>> ?NETCFO Can't find Output Circuit parameter
>>>>
>>>> *SOL*::
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>>>> -1 -1
>>>> STORTR (59.1016) =>GRE-16 /
>>>> ?NETCFO Can't find Output Circuit parameter
>>>>
>>>> *FENCER*::
>>>>
>>>> From Via Back Thru Cost Hops
>>>> VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
>>>> A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016)
>>>> -1 -1
>>>> STORTR (59.1016) =>GRE-16 /
>>>> ?NETPTH NTMAN failed, reason:
>>>> Parameter missing
>>>> $
>>>>
>>>>
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>
>>
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
8:01 p.m.
On Apr 11, 2023, at 1:00 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
Regarding its performance, I don't think netpth was ever a candidate for full
productization, apparently being more of an internal tool for DECnet specialists.
However, this is only a guess.
From the edit history, it looks like it started out life in 1982 being put together by
Stu Grossman, who I thought was working on Stanford at the time. That would be surprising
as I had thought Stanford didn't run Tops-10. But maybe I'm wrong on both counts.
It then appears to have been adopted by Bill Davenport, Gunnar Lindell and Carl Appellof.
I don't know about Bill or Gunnar, but I'm pretty sure I remember Carl being at
DEC.
I would guess netpth was part of a Tops-10 SWSKIT and was then partially ported to
Tops-20. It only uses those Tops-20 JSYi that are necessary to do its job. Since Phase
IV DECnet on the PDP-10 was first developed under Tops-10 (where it could run in user
mode) and then ported to Tops-20 (it's all under conditional assembly), the API's
are remarkably similar. What I mean by that is the Tops-10 UUO and Tops-20 JSYS calling
interface are nearly plug compatible with the exception of the UUO having more flexible
register scheduling.
So, I think the crashing is due to error conditions that weren't anticipated in those
early days, that is, that you would never not get told what the adjacent nodes were. It
is also not impossible that some of the fixes that I put into Tops-20 to report secondary
error conditions could be triggering this.
I do remember netpth working at some point, Peter Lothberg demonstrated it about a year
and a half ago on 10/21/21, viz:
[Routing path from MRC (59.41) to LEGATO (2.1)]
From Via Back Thru Cost Hops
MRC (59.41) =>NI-0-0 / TAP-0 <= OPS1VA (59.59) -1 -1
OPS1VA (59.59) =>GRE-3 / GRE-4 <= IAD2 (59.1020) -1 -1
IAD2 (59.1020) =>DMC-0 / MUL-59-1020 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>TAP-0 / QNA-1 <= LEGATO (2.1) -1 -1
I ran a few tests looking for various PyDECnet versions and their responses to a SHOW
NODE xxx:: STATUS, viz:
Node
PyDECnet Version
Next Node?
A2RTR::
V1.0-596
Yes
PYRTR::
T1.1-640
No
STORTR::
*** Not Reported ***
Yes (Numeric, Only)
DEC000::
V1.0-583
No
NOVA::
V1.0-596
Yes
A29RT2::
T1.1-648
No
This suggested running a test through the older versions, which worked, viz:
[Routing path from VENTI2 (2.522) to SAMV02 (2.152)]
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) 10 3
A2RTR (2.1023) =>MUL-2-150 / MUL-1 <= SAMISH (2.199) 9 2
SAMISH (2.199) =>ETH-0 / UNA-0 <= SAMV02 (2.152) 4 1
So what is this? A newer version of PyDECnet isn't 'doing the right thing'?
I didn't realize that. T1.1 will report next node if it's in the same area or if
it's adjacent. It should do so also if it's in a different area, and I have coded
that fix.
The "numeric only" happens if the node number in question isn't in the node
name database of that particular node.
paul
8:39 p.m.
In reverse order, I think the numeric-only concern is addressed easily
enough, assuming you think your own local executor's node data base is
up to date.
This is more or less the case on TOMMYT:: and VENTI2::, which download
the latest and greatest from MIM:: on a weekly basis and then use my
SETNODE rewrite to compute the set difference between the current and
new definitions in order to change as little as possible in the
monitor's volatile storage.
In short, if the remote node doesn't know, try recovering by asking the
local executor. That seems straightforward.
The question in my mind is what is 'reasonable' for netpth do to recover
if it doesn't get told the next node? By reasonable, I mean is the
process algorithmic (I.E., do this that or the other thing) or heuristic
(I.E., here are some good guesses) ?
------------------------------------------------------------------------
On 4/11/23 2:01 PM, Paul Koning wrote:
I didn't realize that. T1.1 will report next node if it's in the same
area or if it's adjacent. It should do so also if it's in a different
area, and I have coded that fix.
The "numeric only" happens if the node number in question isn't in the
node name database of that particular node.
paul
> ------------------------------------------------------------------------
> On Apr 11, 2023, at 1:00 PM, Thomas DeBellis
> <tommytimesharing(a)gmail.com> wrote:
>
> Regarding its performance, I don't think netpth was ever a candidate
> for full productization, apparently being more of an internal tool
> for DECnet specialists. However, this is only a guess.
>
> From the edit history, it looks like it started out life in 1982
> being put together by Stu Grossman, who I thought was working on
> Stanford at the time. That would be surprising as I had thought
> Stanford didn't run Tops-10. But maybe I'm wrong on both counts. It
> then appears to have been adopted by Bill Davenport, Gunnar Lindell
> and Carl Appellof. I don't know about Bill or Gunnar, but I'm pretty
> sure I remember Carl being at DEC.
>
> I would guess netpth was part of a Tops-10 SWSKIT and was then
> partially ported to Tops-20. It only uses those Tops-20 JSYi that
> are necessary to do its job. Since Phase IV DECnet on the PDP-10 was
> first developed under Tops-10 (where it could run in user mode) and
> then ported to Tops-20 (it's all under conditional assembly), the
> API's are remarkably similar. What I mean by that is the Tops-10 UUO
> and Tops-20 JSYS calling interface are nearly plug compatible with
> the exception of the UUO having more flexible register scheduling.
>
> So, I think the crashing is due to error conditions that weren't
> anticipated in those early days, that is, that you would never /not/
> get told what the adjacent nodes were. It is also not impossible
> that some of the fixes that I put into Tops-20 to report secondary
> error conditions could be triggering this.
>
> I do remember netpth working at some point, Peter Lothberg
> demonstrated it about a year and a half ago on 10/21/21, viz:
>
> [Routing path from MRC (59.41) to LEGATO (2.1)] From Via Back
> Thru Cost Hops MRC (59.41) =>NI-0-0 / TAP-0 <= OPS1VA (59.59) -1
> -1 OPS1VA (59.59) =>GRE-3 / GRE-4 <= IAD2 (59.1020) -1 -1 IAD2
> (59.1020) =>DMC-0 / MUL-59-1020 <= A2RTR (2.1023) -1 -1 A2RTR
> (2.1023) =>TAP-0 / QNA-1 <= LEGATO (2.1) -1 -1
>
> I ran a few tests looking for various PyDECnet versions and their
> responses to a SHOW NODE /xxx/:: STATUS, viz:
>
> *Node*
>
>
>
> *PyDECnet Version*
>
>
>
> *Next Node?*
>
> A2RTR::
>
>
>
> V1.0-596
>
>
>
> Yes
>
> PYRTR::
>
>
>
> T1.1-640
>
>
>
> No
>
> STORTR::
>
>
>
> /*** Not Reported ***/
>
>
>
> Yes (Numeric, Only)
>
> DEC000::
>
>
>
> V1.0-583
>
>
>
> No
>
> NOVA::
>
>
>
> V1.0-596
>
>
>
> Yes
>
> A29RT2::
>
>
>
> T1.1-648
>
>
>
> No
>
> This suggested running a test through the older versions, which
> *worked*, viz:
>
> [Routing path from VENTI2 (2.522) to SAMV02 (2.152)] From Via
> Back Thru Cost Hops VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR
> (2.1023) 10 3 A2RTR (2.1023) =>MUL-2-150 / MUL-1 <= SAMISH
> (2.199) 9 2 SAMISH (2.199) =>ETH-0 / UNA-0 <= SAMV02 (2.152) 4 1
>
> So what is this? A newer version of PyDECnet isn't 'doing the right
> thing'?
8:54 p.m.
On Apr 11, 2023, at 2:39 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
In reverse order, I think the numeric-only concern is addressed easily enough, assuming
you think your own local executor's node data base is up to date.
This is more or less the case on TOMMYT:: and VENTI2::, which download the latest and
greatest from MIM:: on a weekly basis and then use my SETNODE rewrite to compute the set
difference between the current and new definitions in order to change as little as
possible in the monitor's volatile storage.
In short, if the remote node doesn't know, try recovering by asking the local
executor. That seems straightforward.
In your case, the "local executor" would be the NETPHT utility, because
that's the one sending NICE messages to the remote node, right? If the remote node,
the one you're asking for the equivalent of "show node <foo> status",
doesn't know a name for some node number it mentions in the response, it sends just
the address. When processing that response you could indeed supply the name, so if you
want to extend NETPTH to do so that's an option.
The question in my mind is what is
'reasonable' for netpth do to recover if it doesn't get told the next node?
By reasonable, I mean is the process algorithmic (I.E., do this that or the other thing)
or heuristic (I.E., here are some good guesses) ?
Do "show active nodes" and pick up the adjacent node info from the circuit
matching the next-hop circuit in the show node data.
paul
2:32 p.m.
On Apr 10, 2023, at 9:04 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
Yes, I was catching up on that, but perhaps not keeping up with it...
So what's the bottom line here? Is netpth rolling over and dying actually legitimate
or is there a better algorithm to use?
It shouldn't crash, though of course there might be situations where it can't find
the answer because the nodes on the path are not cooperating.
But it still isn't clear to me just what netpth is doing and where/how it is failing
in your tests.
paul
1016
days inactive
1017
days old
31 comments
3 participants
participants (3)
-
Johnny Billquist -
Paul Koning -
Thomas DeBellis