Nagios Support Forum

--e89a8ff25610906ef204d27a3a5c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=F6fgren 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"
> wrote:
>
>> Hi everyone,
>>
>> I'm currently trying to figure out the "on-the-wire" protocol NRPE speak=
s
>> 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/I=
P
>> and am not too sufficient in C. Therefore I'd love to know where and whe=
n 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) =
=3D
>> 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=3D512
>> as NRPE_PACKET_VERSION_2 defines it in common.h
>> - 256 is the packet type 1*256=3D256 as common.h defines it
>> QUERY_PACKET 1
>> - 22286 the checksum over the packet which I - for now - blindly trust i=
s
>> 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 a=
nd
>> 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/lis ... gios-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

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: andreas.marschke@gmail.com