[HECnet] Effects of Rogue Duplicate HECnet Node?

[Thomas DeBellis]

That's interesting that there is no user visible interface to map 
between nodes and area.numbers in RSX, just like Tops-20.  I wonder 
why?  As a contrast, we all know that IP4 and IP6 addresses can be 
specified both numerically and 'symbolically' via the DNS. However, the 
functionality existed in the HOSTS file and predates IP.

Tops-20 does not precisely have a permanent node database. Everything is 
configured and loaded either from text files or 'compiled' text files on 
boot up.  So initial configuring for DECnet and setting the local node 
name and type is done in CONFIG.CMD which is parsed by SETSPD before 
Galaxy is initiated. While that is happening, the 'compiled' (I.E., 
binary) node database is inserted into the hash table.  SETNOD does not 
have full functionality to add and remove nodes from this table, 
although it can tell the monitor to remove a node.

After the insert is done, enough functionality is available for 
SYSTEM.CMD to be parsed by OPR and issue the remaining NCP commands to 
the local NICE processor (NMTL20).  Strangely enough, CLEAR NODE xx:: 
ALL didn't have any effect.  It probably should have.  PURGE didn't work 
at all.  So, you have to do the (undocumented) SETNOD feature to remove 
a node.

!opr
OPR>ent ncp
NCP>push

  PANDA TOPS-20 Command processor 7.1(4454)-5
  End of TOMMYT:<SLOGIN>COMAND.CMD.12
@i dec
  Local DECNET node: VENTI2.  Nodes reachable: 6.
  Accessible DECNET nodes are:    A2RTR    APOLLO LEGATO    TOMMYT    
VENTI2    ZITI
@pop
NCP>tel ziti:: shoW eXECUTOR
NCP>
13:31:21     NCP
         Request # 11 Accepted
NCP>
13:31:21     NCP

Request # 11; Show Executor Node Summary Completed

Executor Node = 2.16 (ZITI)


   Circuit = eth1
   State = On
   Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>clEAR noDE ziti:: alL
NCP>
13:31:42     NCP

Request # 12; Clear Node Completed
NCP>telL ziti:: shoW exECUTOR
NCP>
13:31:58     NCP
         Request # 13 Accepted
NCP>
13:31:59     NCP

Request # 13; Show Executor Node Summary Completed

Executor Node = 2.16 (ZITI)


   Circuit = eth1
   State = On
   Identification = DECnet for Linux V4.4.0-148-generic on x86_64
NCP>push
@i dec
  Local DECNET node: VENTI2.  Nodes reachable: 6.
  Accessible DECNET nodes are:    A2RTR    APOLLO LEGATO    TOMMYT    
VENTI2    ZITI
@pop

NCP>purGE noDE ziti:: alL
NCP>
13:45:47     NCP

Request # 14; Purge Node Failed, Operation failure

NCP>

------------------------------------------------------------------------
On 3/7/20 12:41 PM, Johnny Billquist wrote:
> On 2020-03-04 00:57, Thomas DeBellis wrote:
>> However, as I've said before (viz., the NFT: device and FTS), there 
>> are parts of Tops-20 DECnet that strike me as not fully productized.  
>> One example is that there is no way for /anybody/ to extract the area 
>> and number of a node once it is the monitor.  You can (and should) 
>> verify that the node is 'legitimate' by using .NDVFY function of the 
>> NODE% JSYS, which will also tell you some interesting things about 
>> it. However, it will not divulge the aforementioned numbers.  It 
>> annoyed me enough so that I modified the monitor to do just that with 
>> an additional function, .NDVFX and I use this in DAP (but don't 
>> depend on it) and in the mailer (where I do).
>>
>> I haven't posted the changes anywhere because I can't make up my mind 
>> whether this was fixing an oversight or breaking a design decision or 
>> indeed, whether that should even matter.
>
> In RSX there is no documented way to map between node names and 
> addresses, in either direction.
> There is an interface for it, but it's not documented. Internally, 
> DECnet have a separate device and ACP which handles the nodename 
> database. If you just have the specifications for this device, you can 
> do lookups yourself, but DEC never intended that anyone should use it, 
> except DECnet internally does.
>
>> Another example is that, once a node is inserted into the monitor 
>> data base, there is *no* documented way to remove it.  As I was 
>> implementing .NDVFX, I was looking at the in-area hashing code and 
>> noticed that it appears that the monitor will remove a node marked as 
>> -1 (36 bits).  I have yet to test this.  Certainly SETNOD gives no 
>> hint (another reason I'm toying with a rewrite).
>>
>> Curiouser and curiouser.  Do the above two functionalities exist in 
>> other operating systems?
>
> The ability to remove nodes from the nodename database works fine in 
> pretty much all OSes I know of, except for the PDP-10 world.
> In VMS and RSX, it's NCP CLEAR NODE node ALL, for example, for the 
> current running system. In VMS you use PURGE in NCP for the permanent 
> database, while in RSX, you use PURGE, but in CFE, which is the 
> configuration file editor, for the permanent database.
>
> I think RSTS/E does it all through NCP, like in VMS, but I guess Paul 
> can tell for sure.
>
>   Johnny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200307/a4592f7f/attachment.html>