RFC: NRPE Protocol

[Andreas Marschke]

Hi Anton,

looking at the source code from the POE::Component::Client::NRPE module
again I guess you're right it should be 'N' instead of 'n'.

Thanks for the hint.


On Fri, Jan 4, 2013 at 6:15 PM, Anton Löfgren <alofgren at op5.com> wrote:

> 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
>>
>>
>
> ------------------------------------------------------------------------------
> 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/5122e502/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