RFC: NRPE Protocol

[Anton Löfgren]

Hello,

While not fluent in perl, shouldn't that n in your unpack template be an N
for unsigned long (as opposed to not for unsigned short)?

/Anton
On 4 Jan 2013 17:38, "Andreas Marschke" <andreas.marschke at gmail.com> wrote:

> 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.
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20130104/2ef1c5d4/attachment.html>
-------------- 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