DECnet proxy nor working in one direction?

[cct]

I have two X86 installations under KVM. VMS2 is E9.2-1 and VMS1 is V9.2-1

For my user account, I have proxies on both nodes:

VMS1:
UAF> show/prox VMS2::TOWNLEYC

Default proxies are flagged with (D)

LOCAL:.VMS2::TOWNLEYC
TOWNLEYC (D)

VMS2:
LOCAL:.VMS1::TOWNLEYC
TOWNLEYC (D)

However accessing VMS2 from VMS1 fails, unless I supply credentials. It works fine the other way around. Therer are no conflicting proxies setup

Any ideas what I might have missed?

Chris

[sms]

Code: Select all

> Any ideas what I might have missed?

   Which DECnet?

   Do all the nodes agree on all their DECnet (and/or IP?) addresses?

   I'd hope to find clues in the OPCOM messages on the uncooperative
target node.  (Or ANAL /AUDIT reports?)

   I have dim recollections (perhaps accurate) involving confusion when
a SIMH VAX ("WISP") was using IP for DECnet traffic (without my
noticing), and I (believe that I) had to add a suitable proxy on my main
(IA64) system:

WISP.ANTINODE.INFO::SYSTEM
    SYSTEM (D)

because the usual style:

LOCAL:.WISP::SYSTEM
    SYSTEM (D)

failed.

[arne_v]

The key to finding a solution must be to determine what really happened.

error message, operator.log audit log, show intrusion etc..

[cct]

DECNET Plus

Only error which stated

-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node

which correctly set up an intrusion record:

Code: Select all

%%%%%%%%%%%  OPCOM  26-JUL-2023 18:39:13.72  %%%%%%%%%%%
Message from user SYSTEM on VMS2
Event: Access Control Violation from: Node LOCAL:.VMS2 Session Control,
        at: 2023-07-26-18:39:13.729+01:00Iinf
        NSAP Address=49::00-01:AA-00-04-00-0B-04:21,
        Source=UIC = [0,0]TOWNLEYC,
        Destination=number = 17,
        Destination User="",
        Destination Account="",
        Node Name=
        eventUid   B7DC1934-2BE3-11EE-8E68-AA0004000A04
        entityUid  8906D827-296F-11EE-85B0-AA0004000A04
        streamUid  8D6B67E6-296F-11EE-890F-AA0004000A04

It looks as if it it is just not using the default proxy. Using VMS2"user password:: works fine.

Chris

[volkerhalle]

Chris,

try again with username/pwd, then look at the NET$SERVER.LOG file on the remote system to find out, with which nodename this connection is formed. Then try that string as the proxy.

Volker.

[cct]

Thanks Volker - I should have checked that, but now I am confused!

An access from VMS1 shows on VMS2 as 1035:: whuch is consistent with its address. I have registered them using DECNET_REGISTER, where I am only using local file.

On VMS1 I see:
Directory Service: Local name file

Node name: LOCAL:.MINE
Phase IV synonym: VMS1
Node address: 49::00-01:AA-00-04-00-0B-04:20 (1.11)
Node address: 49::00-01:AA-00-04-00-0B-04:21 (1.11)

Node name: LOCAL:.VMS2
Phase IV synonym: VMS2
Node address: 49::00-01:AA-00-04-00-0A-04:20 (1.10)
Node address: 49::00-01:AA-00-04-00-0A-04:21 (1.10)


On VMS2 I see:
Directory Service: Local name file

Node name: LOCAL:.VMS1
Phase IV synonym: VMS1
Node address: 49::00-01:AA-00-04-00-0B-04:20 (1.11)

Node name: LOCAL:.VMS2
Phase IV synonym: VMS2
Node address: 49::00-01:AA-00-04-00-0A-04:21 (1.10)
Node address: 0.0.0.0
Node address: 49::00-01:AA-00-04-00-0A-04:20 (1.10)

Have I still missed something?

Chris

[volkerhalle]

Chris,

the address information from DECnet_REGISTER does not completely look symmetric on both nodes.

The Event message you've posted from VMS2 shows:

NSAP Address=49::00-01:AA-00-04-00-0B-04:21

but there is only a NSP address (:20) defined for node VMS1 on node VMS2 and not a TP4 address (:21). This may be the reason for the Access Control Violation - and the proxy not working.

Volker.

[cct]

Tried that, but that wasn' the issue - I wasn't thinking when I created the Local full name!

Recreated in NET$CONFIGURE and all is well

Thanks for your help

Chris