No data was received from host!

[tgriep]

Please post the nsclient.log file so we can check it for errors.

[robert.anderko]

hi all,
fresh installation of NSclient++ 0.4.4.23-x64 with nsclient.ini from my previous post

On target system:

Code: Select all

netstat -an |findstr 12489
TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
TCP    10.82.186.11:12489     0.0.0.0:0              LISTENING
TCP    10.82.186.11:12489     10.82.186.11:50121     ESTABLISHED
TCP    10.82.186.11:50121     10.82.186.11:12489     ESTABLISHED
TCP    [::]:12489             [::]:0                 LISTENING

From Nagios server:

Code: Select all

nmap 10.82.186.11 -p T:12489

Starting Nmap 6.47 ( http://nmap.org ) at 2017-08-17 08:29 CEST
Nmap scan report for cz-prgfts011 (10.82.186.11)
Host is up (0.00058s latency).
PORT      STATE SERVICE
12489/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

&

Code: Select all

telnet 10.82.186.11 12489
Trying 10.82.186.11...
Connected to 10.82.186.11.
Escape character is '^]'.

^CConnection closed by foreign host.

From my point of view all seems fine - nsclient++ listening on port 12489, nsclient++ is accessible from Nagios server, communication between Nagios and client is allowed.

I trying run:

Code: Select all

/usr/local/nagios/libexec/check_nt -H 10.82.186.11 -s "" -p 12489 -v CPULOAD -l 5,90,95
No data was received from host!
could not fetch information from server

On target system i see - connection from Nagios server is Established

Code: Select all

netstat -an |findstr 12489
  TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
  TCP    10.82.186.11:12489     0.0.0.0:0              LISTENING
  TCP    10.82.186.11:12489     10.43.174.4:60922      ESTABLISHED
  TCP    10.82.186.11:12489     10.82.186.11:50121     ESTABLISHED
  TCP    10.82.186.11:50121     10.82.186.11:12489     ESTABLISHED
  TCP    [::]:12489             [::]:0                 LISTENING

Log file on attach

[robert.anderko]

resolved. please close

[tgriep]

To help out other people, what did you do to resolve the issue?

[robert.anderko]

debug:c:\source\nscp\include\socket/server.hpp:95: Binding to: 0.0.0.0:12489(ipv4), reopen: true, reuse: true
debug:c:\source\nscp\include\socket/server.hpp:202: Attempting to bind to: 0.0.0.0:12489(ipv4)

This was tested with netstat:

Code: Select all

netstat -an |findstr 12489
  TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:12489          0.0.0.0:0              LISTENING
  TCP    10.82.186.11:12489     0.0.0.0:0              LISTENING
  TCP    10.82.186.11:12489     10.43.174.4:60922      ESTABLISHED
  TCP    10.82.186.11:12489     10.82.186.11:50121     ESTABLISHED
  TCP    10.82.186.11:50121     10.82.186.11:12489     ESTABLISHED
  TCP    [::]:12489             [::]:0                 LISTENING

Due this informations i had in minds "NSClient works fine and listening for connections" .

I stopping NSCP service and run netstat on to TCP port 12489. And positive match:

Code: Select all

netstat -ano |findstr 12489
  TCP    10.82.186.11:12489     0.0.0.0:0              LISTENING       19104
  TCP    10.82.186.11:12489     10.43.174.4:57928      ESTABLISHED     19104
  TCP    10.82.186.11:12489     10.43.174.4:57934      ESTABLISHED     19104
  TCP    10.82.186.11:12489     10.82.186.11:50121     ESTABLISHED     19104
  TCP    10.82.186.11:50121     10.82.186.11:12489     ESTABLISHED     2192

Code: Select all

tasklist /svc /FI "PID eq 19104"

Image Name                     PID Services
========================= ======== ============================================
java.exe                     19104 N/A

Its clear and understable? But question is - why is in debug log from nsclient info about binding to the TCP port, when this is not a true?

[tgriep]

Ah, so there was another process using port 12489 and it was conflicting with NSClient++ and that was causing the error.
I am guessing that the log entry is just saying that it is trying to listen on that port but is not checking that is actually can.
Glad you figured it out.