[HECnet] Effects of Rogue Duplicate HECnet Node?

[Thomas DeBellis]

I took Bob's note as an invitation to perform a little experiment on 
ZITI::.  It looks like my suspicions were confirmed; if the node name 
isn't in Tops-20's hash table, then you are not going there, no way, no how.

  * I verified that ZITI:: was in my area, online and that I could do a
    SHOW EXECUTOR,
  * I then undefined poor ZITI::, noticing that it subsequently was
    reported as offline (clearly a vicious calumny).
  * The NICE process (NCP) could no longer communicate with it either by
    name /or by number/.
  * When I redefined ZITI:: with SETNOD, SHOW EXECUTOR started working
    again.

I wonder why they never allowed real area.number connections in 
Tops-20?  I mean other than they were running away from the product...  
Hum...

!i dec
  Local DECNET node: VENTI2.  Nodes reachable: 6.
  Accessible DECNET nodes are:    A2RTR    APOLLO LEGATO    TOMMYT    
VENTI2    ZITI
!opr
OPR>enter ncp
NCP>telL ziti:: shoW exeCUTOR
NCP>
23:20:29     NCP
         Request # 5 Accepted
NCP>
23:20:30     NCP

Request # 5; Show Executor Node Summary Completed

Executor Node = 2.16 (ZITI)


   Circuit = eth1
   State = On
   Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>push

  PANDA TOPS-20 Command processor 7.1(4454)-5
  End of TOMMYT:<SLOGIN>COMAND.CMD.12
@enable
!setnod
SETNOD>set nODE -1 . -1 nAME ZITI
SETNOD>insert
SETNOD>exi
!i dec
  Local DECNET node: VENTI2.  Nodes reachable: 5.
  Accessible DECNET nodes are:    A2RTR    APOLLO LEGATO    TOMMYT    VENTI2
!pop
NCP>telL ziti:: shoW exeCUTOR
NCP>
23:22:13     NCP
         Request # 6 Accepted

23:22:13     NCP

Request # 6; Show Executor Node Summary Failed, Listener link connect 
failed,
Link Failure = Node unreachable

NCP>telL 2.16 shoW exECUTOR
NCP>
23:22:23     NCP
         Request # 7 Accepted

23:22:23     NCP

Request # 7; Show Executor Node Summary Failed, Invalid identification,
Node address has no matching node name


NCP>
23:22:28       -- DECnet link message --

Communication failure to the following nodes:
ZITI
NCP>push
!c setnod
SETNOD>set nod 2.16 name ziti
SETNOD>insert
SETNOD>exi
!i dec
  Local DECNET node: VENTI2.  Nodes reachable: 6.
  Accessible DECNET nodes are:    A2RTR    APOLLO LEGATO    TOMMYT    
VENTI2    ZITI
!pop
NCP>tel ziti:: shoW exeCUTOR
NCP>
23:23:35     NCP
         Request # 8 Accepted
NCP>
23:23:36     NCP

Request # 8; Show Executor Node Summary Completed

Executor Node = 2.16 (ZITI)


   Circuit = eth1
   State = On
   Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>exit

------------------------------------------------------------------------
On 3/3/20 10:38 PM, Robert Armstrong wrote:
>> The area.node notation, and the Phase 3 numeric address notation, were
>> intended to be standard, not just limited to NCP.  And indeed DECnet/E
>> (in RSTS) does both:
>    FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and
> 2064::.  It also accepts the node"name password":: notation as well.
> Actually I thought this was a standard thing in all "modern" (i.e. Phase IV)
> implementations.  Are there systems that don't?
>
>    And the VMS parser doesn't limit the node name to 6 characters, so you can
> say "63.1023::" (although HECnet has no such node).
>
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200303/44a4c33e/attachment.html>