Re: RV: Problem with "check_tcp"

* Julio Pedreira Paz <[email protected]> [2013-09-09 13:57]:
> I know that the server performs a "flush" after the first 5 bytes are
> ready but it does not close the connection. Its just that the server
> flushes parts of the response as soon as it has them ready. Tracking
> this to "check_tcp" source code, I found:
> 
>         /* watch for the expect string */
>         while ((i = my_recv(buffer, sizeof(buffer))) > 0) {
>                  status = realloc(status, len + i + 1);
>                  memcpy(&status[len], buffer, i);
>                  len += i;
> 
>                  /* stop reading if user-forced or data-starved */
>                  if(i < sizeof(buffer) || (maxbytes && len >= maxbytes))
>                           break;
> 
> If I'm not wrong, the "i < sizeof(buffer)" condition means to leave the
> reading loop if the bytes received are less than the buffer size, wich
> makes no sense to me, as other bytes may be awainting in the server, as
> it was my case. In fact, if I comment that condition and recompile, it
> works as expected.
> 
> Is it a bug or just something I'm missing?

It's a bug, the author of those lines obviously assumed that check_tcp
would always receive the data in one go.

Could you submit a pull request on GitHub (or shall I fix this myself)?

Holger

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________________
Nagios Plugin Development Mailing List Nagiosplug-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null