--20cf307cfd4c1292d004d279a174
Content-Type: text/plain; charset=ISO-8859-1
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 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/lis ... gios-devel
>
>
--20cf307cfd4c1292d004d279a174
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello,
While not fluent in perl, shouldn't that n in your unpac=
k 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@gmail.=
com> wrote:
<span style=3D"font-family:arial,sans-
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: alofgren@op5.com