RFC: NRPE Protocol

Andreas Marschke andreas.marschke at gmail.com
Fri Jan 4 09:30:45 CET 2013


Hi everyone,

I'm currently trying to figure out the "on-the-wire" protocol NRPE speaks
so I could implement a pure perl module that could talk NRPE.

During this endeavour I found a couple of strange things I'd like to ask
you folks about.

Beware that this is my first time I write an application using raw TCP/IP
and am not too sufficient in C. Therefore I'd love to know where and when I
went wrong in my assumptions and/or code.

As mentioned above I use Perl as my target language and simultainously
started reading the code in check_nrpe.c . So far I came up with this as an
unpack template:

my ($packet_version, $packet_type, $crc32_value, $result_code, $buffer) =
unpack('S S n S A[1024]',$str);

print $packet_version." ".$packet_type." ".$crc32_value." ".$result_code."
".$buffer;

Where $str is the hex encoded data from the TCP conversation and is
attached to this mail(data.hex). As a result I get this:

512 256 22286 20613 krcheck_users

>From looking at the code I can gather that:

- 512 is the NRPE version 2*256=512
  as NRPE_PACKET_VERSION_2  defines it in common.h
- 256 is the packet type 1*256=256 as common.h defines it
  QUERY_PACKET 1
- 22286 the checksum over the packet which I - for now - blindly trust is
correct
Now this os where it starts boggling in my mind. common.h defines packet
as:

typedef struct packet_struct{
        int16_t   packet_version;
        int16_t   packet_type;
        u_int32_t crc32_value;
        int16_t   result_code;
        char      buffer[MAX_PACKETBUFFER_LENGTH];
        }packet;

So logically a result and/or zero should be here for a Query package right?
But what I find is:
- 20613

After that there is only $buffer left which is:
"krcheck_users"
Which is semi-correct since I queried the server for the state of
check_users. But the first 2 characters bother me. They showed up
consistently over the last 4-5 test packets I looked at with wireshark and
were always semi random. If I could find an explanation for them I'd be
happy. Otherwise maybe I'm just wrong in assuming that result_code is
actually relevant in this context and it is actually part of the
semi_random data you filled packet with before filling in the relevant
parts.

Otherwise I'd love to have something in the form of an RFC for the NRPE
Protocol versions. This would definitely make implementing NRPE much
easier.

Thanks in advance and a Happy New Year,

Andreas Marschke.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20130104/234f5cf2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.hex
Type: application/octet-stream
Size: 4144 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20130104/234f5cf2/attachment.obj>
-------------- next part --------------
------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list