CHECK_NRPE: Invalid packet type received from server #83

Closed
willemdh opened this Issue Jan 17, 2015 · 15 comments

Comments

Projects
None yet
4 participants
@willemdh

Hello,

I upgraded to 0.4.3.88 yesterday on a WIndows 2012 R2. Did some tests today and I seem to have multiple Powershell scripts that are failing with the message "CHECK_NRPE: Invalid packet type received from server." These work fine on 0.4.1.105 and older Windows versions.
When I execute the scripts locally on the server they work fine.
I did an nscp test and got multiple errors, mostly because nsclient.log cannot be found (and indeed it didn't exist)

C:\Program Files\NSClient++>nscp test
L client Module: CommandClient
C:\Program Files\NSClient++\nsclient.log could not be opened, Discarding: message: Module: CommandClient
L client Command:

After doing some tests, it seems I only get the error when the output is longer. Executing a Powershell script with a short 'write-host' output seems to work fine. From the moment the output is longer (not sure exactly how long) I seem to get "CHECK_NRPE: Invalid packet type received from server"

'''[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.
use ssl = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not the we will allow clients to specify nasty (as in |`&><'"[]{}) characters in arguments.
allow nasty characters = 1

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the we will allow clients to specify arguments to commands that are executed.
allow arguments = 1

; PORT NUMBER - Port to use for NRPE.
port = 5666

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client.
insecure = true

; VERIFY MODE - Comma separated list of verification flags to set on the SSL socket.
verify mode = none

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to go beyond payload size (requires modified client).
extended response = 0

timeout = 300
'''
Tried setting 'extended response to 0 and 1, but makes no difference. Is there something else I'm forgetting?

Thanks.

Willem

@mathieuchateau

This comment has been minimized.

Show comment
Hide comment
@mathieuchateau

mathieuchateau Jan 17, 2015

Collaborator

Hello,

Did you start your cmd with run as administrator ? else nscp can't write
the nsclient.log as it's in program files

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:34 GMT+01:00 willemdh notifications@github.com:

Hello,

I upgraded to 0.4.3.88 yesterday on a WIndows 2012 R2. Did some tests
today and I seem to have multiple Powershell scripts that are failing with
the message "CHECK_NRPE: Invalid packet type received from server." These
work fine on 0.4.1.105 and older Windows versions.
When I execute the scripts locally on the server they work fine.
I did an nscp test and got multiple errors, mostly because nsclient.log
cannot be found (and indeed it didn't exist)

C:\Program Files\NSClient++>nscp test
L client Module: CommandClient
C:\Program Files\NSClient++\nsclient.log could not be opened, Discarding:
message: Module: CommandClient
L client Command:

After doing some tests, it seems I only get the error when the output is
longer. Executing a Powershell script with a short 'write-host' output
seems to work fine. From the moment the output is longer (not sure exactly
how long) I seem to get "CHECK_NRPE: Invalid packet type received from
server"

[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.
use ssl = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not
the we will allow clients to specify nasty (as in |`&><'"[]{}) characters
in arguments.
allow nasty characters = 1

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the
we will allow clients to specify arguments to commands that are executed.
allow arguments = 1

; PORT NUMBER - Port to use for NRPE.
port = 5666

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are
using legacy check_nrpe client.
insecure = true

; VERIFY MODE - Comma separated list of verification flags to set on the
SSL socket.

verify mode = none

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to
go beyond payload size (requires modified client).
extended response = 0

timeout = 300

Tried setting 'extended response to 0 and 1, but makes no difference. Is
there something else I'm forgetting?

Thanks.

Willem


Reply to this email directly or view it on GitHub
#83.

Collaborator

mathieuchateau commented Jan 17, 2015

Hello,

Did you start your cmd with run as administrator ? else nscp can't write
the nsclient.log as it's in program files

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:34 GMT+01:00 willemdh notifications@github.com:

Hello,

I upgraded to 0.4.3.88 yesterday on a WIndows 2012 R2. Did some tests
today and I seem to have multiple Powershell scripts that are failing with
the message "CHECK_NRPE: Invalid packet type received from server." These
work fine on 0.4.1.105 and older Windows versions.
When I execute the scripts locally on the server they work fine.
I did an nscp test and got multiple errors, mostly because nsclient.log
cannot be found (and indeed it didn't exist)

C:\Program Files\NSClient++>nscp test
L client Module: CommandClient
C:\Program Files\NSClient++\nsclient.log could not be opened, Discarding:
message: Module: CommandClient
L client Command:

After doing some tests, it seems I only get the error when the output is
longer. Executing a Powershell script with a short 'write-host' output
seems to work fine. From the moment the output is longer (not sure exactly
how long) I seem to get "CHECK_NRPE: Invalid packet type received from
server"

[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.
use ssl = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not
the we will allow clients to specify nasty (as in |`&><'"[]{}) characters
in arguments.
allow nasty characters = 1

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the
we will allow clients to specify arguments to commands that are executed.
allow arguments = 1

; PORT NUMBER - Port to use for NRPE.
port = 5666

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are
using legacy check_nrpe client.
insecure = true

; VERIFY MODE - Comma separated list of verification flags to set on the
SSL socket.

verify mode = none

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to
go beyond payload size (requires modified client).
extended response = 0

timeout = 300

Tried setting 'extended response to 0 and 1, but makes no difference. Is
there something else I'm forgetting?

Thanks.

Willem


Reply to this email directly or view it on GitHub
#83.

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 17, 2015

Ha nscp test seems to work better. Hate uac.. Thanks. ANy idea bout the "CHECK_NRPE: Invalid packet type received from server"?

Ha nscp test seems to work better. Hate uac.. Thanks. ANy idea bout the "CHECK_NRPE: Invalid packet type received from server"?

@mathieuchateau

This comment has been minimized.

Show comment
Hide comment
@mathieuchateau

mathieuchateau Jan 17, 2015

Collaborator

If you know for sure one script output that fails, could you send an
example ?

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:40 GMT+01:00 willemdh notifications@github.com:

Ha nscp test seems to work better. Hate uac.. Thanks. ANy idea bout the
"CHECK_NRPE: Invalid packet type received from server"?


Reply to this email directly or view it on GitHub
#83 (comment).

Collaborator

mathieuchateau commented Jan 17, 2015

If you know for sure one script output that fails, could you send an
example ?

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:40 GMT+01:00 willemdh notifications@github.com:

Ha nscp test seems to work better. Hate uac.. Thanks. ANy idea bout the
"CHECK_NRPE: Invalid packet type received from server"?


Reply to this email directly or view it on GitHub
#83 (comment).

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 17, 2015

Well, seems I found a way to make it work. When I let the nscp service run with an account with admin permissions, it seems to work.
An example of a script => http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2 and 0.4.1.105)) the two above examples work fine with localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012 R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz

Well, seems I found a way to make it work. When I let the nscp service run with an account with admin permissions, it seems to work.
An example of a script => http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2 and 0.4.1.105)) the two above examples work fine with localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012 R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz

@mathieuchateau

This comment has been minimized.

Show comment
Hide comment
@mathieuchateau

mathieuchateau Jan 17, 2015

Collaborator

looks weird.
I have mainly 2012R2 servers on my side.
nsclient run with local system, and i successfully monitor scheduled tasks

Why don't you use the builtin feature of nsclient to check tasks ? that's
what i use without issue

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:55 GMT+01:00 willemdh notifications@github.com:

Well, seems I found a way to make it work. When I let the nscp service run
with an account with admin permissions, it seems to work.
An example of a script =>
http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2) the two above examples work fien with
localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012
R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz


Reply to this email directly or view it on GitHub
#83 (comment).

Collaborator

mathieuchateau commented Jan 17, 2015

looks weird.
I have mainly 2012R2 servers on my side.
nsclient run with local system, and i successfully monitor scheduled tasks

Why don't you use the builtin feature of nsclient to check tasks ? that's
what i use without issue

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:55 GMT+01:00 willemdh notifications@github.com:

Well, seems I found a way to make it work. When I let the nscp service run
with an account with admin permissions, it seems to work.
An example of a script =>
http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2) the two above examples work fien with
localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012
R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz


Reply to this email directly or view it on GitHub
#83 (comment).

@mathieuchateau

This comment has been minimized.

Show comment
Hide comment
@mathieuchateau

mathieuchateau Jan 17, 2015

Collaborator

I guess -H localhost make the script connecting as if it was a remote
system. Local system only works on local system, not remote.

Using domain admin is very very bad from security point of view. Any audit
will shoot you down

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 11:00 GMT+01:00 Mathieu Chateau mathieu.chateau@lotp.fr:

looks weird.
I have mainly 2012R2 servers on my side.
nsclient run with local system, and i successfully monitor scheduled tasks

Why don't you use the builtin feature of nsclient to check tasks ? that's
what i use without issue

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:55 GMT+01:00 willemdh notifications@github.com:

Well, seems I found a way to make it work. When I let the nscp service
run with an account with admin permissions, it seems to work.
An example of a script =>
http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2) the two above examples work fien with
localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012
R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz


Reply to this email directly or view it on GitHub
#83 (comment).

Collaborator

mathieuchateau commented Jan 17, 2015

I guess -H localhost make the script connecting as if it was a remote
system. Local system only works on local system, not remote.

Using domain admin is very very bad from security point of view. Any audit
will shoot you down

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 11:00 GMT+01:00 Mathieu Chateau mathieu.chateau@lotp.fr:

looks weird.
I have mainly 2012R2 servers on my side.
nsclient run with local system, and i successfully monitor scheduled tasks

Why don't you use the builtin feature of nsclient to check tasks ? that's
what i use without issue

Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-01-17 10:55 GMT+01:00 willemdh notifications@github.com:

Well, seems I found a way to make it work. When I let the nscp service
run with an account with admin permissions, it seems to work.
An example of a script =>
http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/NRPE/Check-Microsoft-Windows-Scheduled-Tasks/details

So nscp running as localsystem on W2012R2:
CHECK_NRPE: Invalid packet type received from server:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost'

WORKS:
/usr/local/nagios/libexec/check_nrpe -H testserver2012 -t 60 -p 5666 -c
check_ms_win_tasks -a '-H Localhost -EF Microsoft'

On other servers I have (2008 R2) the two above examples work fien with
localsystem.

Grtz and thanks for your time. The issue might be related to WIndows 2012
R2 and not NSClient 0.4.3.88 as we only recently acquired 2012 R2 licenses.

Grtz


Reply to this email directly or view it on GitHub
#83 (comment).

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 17, 2015

Because I like my version better. And the output displays the owner of the failed tasks, will parse exit codes, return perfdata resulting in graphs which show when tasks are running etc. I had multiple issues monitoring scheduled tasks in the past with Nsclient, so made my own scheduled task check script. Never had any troubles with it.

This is just one example, I have other Powershell script which give similar "CHECK_NRPE: Invalid packet type received from server:" Don't mind -H localhost, it's just sth I pass, as it can do remoting too, but not in the version on Exchange. (still in test)
Not using domain admin by the way, just local admin, as said on 2008 + 0.4.1.105 it works with localsystem.

Because I like my version better. And the output displays the owner of the failed tasks, will parse exit codes, return perfdata resulting in graphs which show when tasks are running etc. I had multiple issues monitoring scheduled tasks in the past with Nsclient, so made my own scheduled task check script. Never had any troubles with it.

This is just one example, I have other Powershell script which give similar "CHECK_NRPE: Invalid packet type received from server:" Don't mind -H localhost, it's just sth I pass, as it can do remoting too, but not in the version on Exchange. (still in test)
Not using domain admin by the way, just local admin, as said on 2008 + 0.4.1.105 it works with localsystem.

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 17, 2015

You can close the issue if you think it has nothing to do with 0.4.3.88. I just did not see this error before. (But i come from 0.4.1.105)

You can close the issue if you think it has nothing to do with 0.4.3.88. I just did not see this error before. (But i come from 0.4.1.105)

@mickem

This comment has been minimized.

Show comment
Hide comment
@mickem

mickem Jan 27, 2015

Owner

I think this is due to the "multi package patch" which is default applied...

Maybe I should to disable that for legacy mode?

I will investigate a bit and get back in the next few days...

Owner

mickem commented Jan 27, 2015

I think this is due to the "multi package patch" which is default applied...

Maybe I should to disable that for legacy mode?

I will investigate a bit and get back in the next few days...

@mickem mickem added the bug label Jan 27, 2015

@mickem mickem added this to the 0.4.3 milestone Jan 27, 2015

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 27, 2015

"Maybe I should to disable that for legacy mode?"

I can't answer this question for you Michael, as I have no idea what the multi package patch is, not what legacy mode is. I trust you make the correct decision.
My Powershell plugin just did no longer seem to work after an upgrade untill I made the service run with local admin account.

"Maybe I should to disable that for legacy mode?"

I can't answer this question for you Michael, as I have no idea what the multi package patch is, not what legacy mode is. I trust you make the correct decision.
My Powershell plugin just did no longer seem to work after an upgrade untill I made the service run with local admin account.

mickem added a commit that referenced this issue Jan 27, 2015

@mickem

This comment has been minimized.

Show comment
Hide comment
@mickem

mickem Jan 27, 2015

Owner

I can confirm this issue and it will be resolved in the next build.

Owner

mickem commented Jan 27, 2015

I can confirm this issue and it will be resolved in the next build.

@mickem

This comment has been minimized.

Show comment
Hide comment
@mickem

mickem Jan 27, 2015

Owner

Just to clearify..

The "multi package patch" is something ton voon created several years ago which allows you to send more then 1024 chars back via NRPE.

With legacy mode I meant the "insecure" old nrpe mode which most are using...

Owner

mickem commented Jan 27, 2015

Just to clearify..

The "multi package patch" is something ton voon created several years ago which allows you to send more then 1024 chars back via NRPE.

With legacy mode I meant the "insecure" old nrpe mode which most are using...

@willemdh

This comment has been minimized.

Show comment
Hide comment
@willemdh

willemdh Jan 27, 2015

Michael,

Thanks for the patch. Yes indeed i'm using the insecure mode. Just read through this:
http://www.medin.name/blog/2012/12/02/securing-nrpe-with-certificate-based-authentication/

Seem interesting. Really. But I'm having my head full of several big projects. Maybe in half a year or so, I'd investigate further.

Grtz

Willem

Michael,

Thanks for the patch. Yes indeed i'm using the insecure mode. Just read through this:
http://www.medin.name/blog/2012/12/02/securing-nrpe-with-certificate-based-authentication/

Seem interesting. Really. But I'm having my head full of several big projects. Maybe in half a year or so, I'd investigate further.

Grtz

Willem

@mickem

This comment has been minimized.

Show comment
Hide comment
@mickem

mickem Jan 29, 2015

Owner

0.4.3.102 should fix this issue, please reopen if issue still persists...

Owner

mickem commented Jan 29, 2015

0.4.3.102 should fix this issue, please reopen if issue still persists...

@borgified

This comment has been minimized.

Show comment
Hide comment
@borgified

borgified May 19, 2015

Contributor

i encountered this issue in version 0.4.3.143 however i was able to get around the issue by piping the STDOUT to a file then retrieving that file later. i verified that the problem occurs when there is too much output by varying the amount of data that would get sent to STDOUT until the problem showed up. i am using legacy mode.

Contributor

borgified commented May 19, 2015

i encountered this issue in version 0.4.3.143 however i was able to get around the issue by piping the STDOUT to a file then retrieving that file later. i verified that the problem occurs when there is too much output by varying the amount of data that would get sent to STDOUT until the problem showed up. i am using legacy mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment