<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
<!--
@font-face
        {font-family:Calibri}
@font-face
        {font-family:"Segoe UI"}
@font-face
        {font-family:Consolas}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
pre
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New"}
span.HTMLconformatoprevioCar
        {font-family:"Courier New"}
span.EstiloCorreo19
        {font-family:"Calibri","sans-serif";
        color:windowtext}
span.cm
        {}
span.k
        {}
span.p
        {}
span.n
        {}
span.o
        {}
span.mi
        {}
span.EstiloCorreo26
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
.MsoChpDefault
        {font-size:10.0pt}
@page WordSection1
        {margin:70.85pt 3.0cm 70.85pt 3.0cm}
div.WordSection1
        {}
-->
</style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">While testing a service with “check_tcp” tool, I ran into a estrange behaviour. Running the same check_tcp command several times resulted in random OK / WARNING results. Reading the service server log, I could assert that the server replied
 always the same response. When using “–v” with “check_tcp” I realized that WARNING messages were due to check_tcp doing an incomplete read of the service response:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">$ check_tcp -H venus -p 22225 -s "0003000000D360PXXXAAAABBBBBBBB" -e "00028D360RXXX" -v</p>
<p class="MsoNormal">Using service TCP</p>
<p class="MsoNormal">Port: 22225</p>
<p class="MsoNormal">flags: 0x2</p>
<p class="MsoNormal">Send string: 0003000000D360PXXXAAAABBBBBBBB</p>
<p class="MsoNormal">server_expect_count: 1</p>
<p class="MsoNormal">        0: 00028D360RXXX</p>
<p class="MsoNormal">received 5 bytes from host</p>
<p class="MsoNormal">#-raw-recv-------#</p>
<p class="MsoNormal">00028</p>
<p class="MsoNormal">#-raw-recv-------#</p>
<p class="MsoNormal">looking for [00028D360RXXX] anywhere in [00028]</p>
<p class="MsoNormal">couldn't find it</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal">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:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="line-height:13.5pt"><i><span style="font-size:9.0pt; font-family:Consolas; color:#999988">                 /* watch for the expect string */</span></i><span style="font-size:9.0pt; font-family:Consolas; color:#333333"></span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                
<b>while</b> ((i <b>=</b> my_recv(buffer, <b>sizeof</b>(buffer))) <b>></b> </span>
<span style="font-size:9.0pt; font-family:Consolas; color:#009999">0</span><span style="font-size:9.0pt; font-family:Consolas; color:#333333">) {</span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                          status
<b>=</b> realloc(status, len <b>+</b> i <b>+</b> </span><span style="font-size:9.0pt; font-family:Consolas; color:#009999">1</span><span style="font-size:9.0pt; font-family:Consolas; color:#333333">);</span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                          memcpy(<b>&</b>status[len], buffer, i);</span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                          len
<b>+=</b> i;</span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333"> </span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                         
</span><i><span style="font-size:9.0pt; font-family:Consolas; color:#999988">/* stop reading if user-forced or data-starved */</span></i><span style="font-size:9.0pt; font-family:Consolas; color:#333333"></span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                         
<b>if</b>(<b>i < sizeof(buffer)</b> <b>||</b> (maxbytes <b>&&</b> len <b>>=</b> maxbytes))</span></p>
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:9.0pt; font-family:Consolas; color:#333333">                                  
<b>break</b>;</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal">If I’m not wrong, the “<b><span style="font-size:9.0pt; font-family:Consolas; color:#333333">i < sizeof(buffer</span></b>)” 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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Is it a bug or just something I’m missing? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thank you!</p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Julio Pedreira Paz</span><span style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Enterprise Architect - IT Architecture & Design</span><span style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"></span></p>
<p class="MsoNormal"><span lang="ES" style="color:#1F497D">Equifax Ibérica</span><span lang="ES" style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"></span></p>
<p class="MsoNormal"><span lang="ES" style="color:#1F497D">Fijo/Land:  +34 91 768 773  (7732)</span><span lang="ES" style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"></span></p>
<p class="MsoNormal"><span lang="ES" style="color:#1F497D">Móvil/Cell: +34 626 721 620  (8732)</span><span lang="ES" style="font-size:13.5pt; font-family:"Segoe UI","sans-serif"; color:black"></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><a href="mailto:julio.pedreira@equifax.es"><span lang="ES">julio.pedreira@equifax.es</span></a></span><span lang="ES" style="color:#1F497D"></span></p>
<p class="MsoNormal"><span lang="ES" style="color:#1F497D"><a href="http://www.equifax.es/">www.equifax.es</a></span></p>
<p class="MsoNormal"><span lang="ES"> </span></p>
</div>
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud
 de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. Esta mensagem destina-se exclusivamente ao destinatário e pode conter informação privilegiada e/ou
 confidencial. Se não é o destinatário da mensagem, fique ciente que a utilização, divulgação e/ou cópia sem autorização, está proibida pela lei actualmente em vigor. Se recebeu esta mensagem por engano, pedimos-lhe que no-lo comunique imediatamente por esta
 mesma via, e proceda à destruição da mesma
</body>
</html>