[HECnet] Multiple nodes failing NICE in the same way

Paul Koning paulkoning at comcast.net
Fri Nov 12 13:43:00 PST 2021



> On Nov 12, 2021, at 4:18 PM, John Forecast <john at forecast.name> wrote:
> 
> 
>> On Nov 12, 2021, at 2:46 PM, Paul Koning <paulkoning at comcast.net> wrote:
>> 
>> My network scanner is getting very strange responses from three different nodes all misbehaving the same way: CAIR, MAGPIE, and FARGO.
>> 
>> What I see is:
>> 
>> 1. The connection to object 19 (NICE, the network management listener) is accepted, but the version number that is supposed to be sent as part of the accept is missing.
>> 
>> 2. When I send a NICE request to the node, I get back a message with this content:
>> 
>> <28>Nov 12 20:35:16 dnetd[1688]: Cannot chdir to /nonexistent : No such file or directory\n\xff\x00\x00
>> 
>> All three nodes do this.  Configuration error that just happens to exist on all three?
>> 
>> 	paul
>> 
> 
> Those systems must be running DECnet for Linux. dnetd performs the mapping from an inbound connect request and runs the appropriate daemon/user application. Assuming the object database (/etc/dnetd.conf) has not been changed from the default, user “nobody” has a home directory of /nonexistent (which does not exist). The warning should be benign since it will default running with the current directory of “/“, although I’m not sure that’s good - “/tmp” may be a better default. I’m not sure where the extra hex values are coming from. Are you seeing this as the reply to the NICE request? It should only be written to syslog.
> 
>  John.
> 

Yes, it appears in response to a NICE request.  What's strange is that the connection is accepted.  If there's something wrong with the object, it shouldn't result  in a connect confirm but rather a connect reject (a.k.a., disconnect initiate with a suitable reason code).  The connect confirm tells the requesting end that the object is operational and ready to accept requests.  If something then goes wrong, that's ok but in that case the requesting end expects an error reply according to the protocol.  In this case that would be some sort of NICE error message reporting a problem executing the request.

	paul




More information about the Hecnet-list mailing list