Re: Notification of Github pull request #1518

Carlos Carvalho <[email protected]> Tue, 2 Apr 2019 11:16:58 +0100
Newsgroups gmane.comp.security.nmap.devel
Message-ID <CANk9pFY7EUKmarE3LfGy0WbbLuxVr60uNgxnCW=8Cwz9jxMbgw@mail.gmail.com>
--===============2447667465064039790==
Content-Type: multipart/alternative; boundary="0000000000009cd3b805858970c0"

--0000000000009cd3b805858970c0
Content-Type: text/plain; charset="UTF-8"

Hi all,

Just to share a bit of follow-up about Nping's [GH#1518]. (I should've done
this _before_ submitting the patch, but hey!)

*What I did*:
Increase the relative timeout between the previous request to the current
one, for the last loop iteration.

*Background*:
*nsock* understands that it is to finish the processing when the last
request is sent. That will cause an *EPOLL_CTL_DEL* (and eventually a
signal *READ_KILL*)
and the execution will end.

The problem is that when it is done there is still one message to be
processed/received, it is the last *CAPT*, but it is killed before having a
chance.

AFAIK it is not an *nsock* issue, it seems to be expected to behave that
way, instead by increasing the timeout for the last iteration of loop
effectively delays the EPOLL_CTL_DEL, as shown in the following *strace*
outputs:

Unmodified Nping:

> write(1, "*SENT* (3.1041s) TCP 192.168.0.8:6"..., 108SENT (3.1041s) TCP
> 192.168.0.8:63648 > 45.33.32.156:92 S ttl=64 id=55812 iplen=40
> seq=3059980532 win=1480
> ) = 108
> epoll_ctl(3, *EPOLL_CTL_DEL*, 4, NULL)    = 0
> close(4)                                = 0
> close(3)                                = 0
> write(1, " \n", 2
> )


Patched version:

> write(1, "*CAPT* (3.5191s) TCP 82.27.182.127"..., 107CAPT (3.5191s) TCP
> 82.27.182.127:6171 > 45.33.32.156:92 S ttl=51 id=6924 iplen=40
> seq=592807962 win=1480
> ) = 107
> epoll_ctl(3, *EPOLL_CTL_DEL*, 4, NULL)    = 0
> close(4)                                = 0
> close(3)                                = 0
> write(1, " \n", 2



The timeout values I choose are arbitrary, fine-tuned to a number that
guaranteed, in my tests, to always succeed in allowing the last *CAPT* line
to be displayed. I believe that the numbers would work all the times
(hopefully!).

Unfortunately I am not hugely experienced with the Nmap code yet so there
could have something there that I am not seeing or foreseeing and a review
would be nice.

Does anyone visualise a better approach? Any bad side-effects that I did
not see?

Thanks

On Sun, 17 Mar 2019 at 22:13, Carlos Carvalho <[email protected]> wrote:

>
> Addresses:
>
> * When running Nping echo client with the --no-capture parameter, the last
>   packet's CAPT line is not displayed.
>
>
>

-- 
Carlos Carvalho

--0000000000009cd3b805858970c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi all,<div><br></div><d=
iv>Just to share a bit of follow-up about Nping&#39;s [GH#1518]. (I should&=
#39;ve done this _before_ submitting the patch, but hey!)</div><div><br></d=
iv><div><i>What I did</i>:</div><div>Increase the relative timeout between =
the previous request to the current one, for the last loop iteration.</div>=
<div><br></div><div><i>Background</i>:</div><div><i>nsock</i> understands t=
hat it is to finish the processing when the last request is sent. That will=
 cause an <i>EPOLL_CTL_DEL</i> (and eventually a signal=C2=A0<i>READ_KILL</=
i>)</div><div>and the execution will end.</div><div><br></div><div>The prob=
lem is that when it is done there is still one message to be processed/rece=
ived, it is the last <i>CAPT</i>, but it is killed before having a chance.<=
/div><div><br></div><div>AFAIK it is not an <i>nsock</i> issue, it seems to=
 be expected to behave that way, instead by increasing the timeout for the =
last iteration of loop</div><div>effectively delays the EPOLL_CTL_DEL, as s=
hown in the following <i>strace</i> outputs:=C2=A0=C2=A0</div><div><br></di=
v><div>Unmodified Nping:</div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">write(1, &quot;<b>SENT</b> (3.1041s) TCP <a href=3D"http://192.1=
68.0.8:6">192.168.0.8:6</a>&quot;..., 108SENT (3.1041s) TCP <a href=3D"http=
://192.168.0.8:63648">192.168.0.8:63648</a> &gt; <a href=3D"http://45.33.32=
.156:92">45.33.32.156:92</a> S ttl=3D64 id=3D55812 iplen=3D40=C2=A0 seq=3D3=
059980532 win=3D1480=C2=A0<br>) =3D 108<br>epoll_ctl(3, <b>EPOLL_CTL_DEL</b=
>, 4, NULL)=C2=A0 =C2=A0 =3D 0<br>close(4)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =3D 0<br>close(3)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0<br>wri=
te(1, &quot; \n&quot;, 2=C2=A0<br>)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</blockquote><div><br></div><div>Patched version:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">write(1, &quot;<b>CAPT</b> (3.5191s) TCP 8=
2.27.182.127&quot;..., 107CAPT (3.5191s) TCP <a href=3D"http://82.27.182.12=
7:6171">82.27.182.127:6171</a> &gt; <a href=3D"http://45.33.32.156:92">45.3=
3.32.156:92</a> S ttl=3D51 id=3D6924 iplen=3D40=C2=A0 seq=3D592807962 win=
=3D1480=C2=A0<br>) =3D 107<br>epoll_ctl(3, <b>EPOLL_CTL_DEL</b>, 4, NULL)=
=C2=A0 =C2=A0 =3D 0<br>close(4)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0=
<br>close(3)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0<br>write(1, &quot; \=
n&quot;, 2=C2=A0</blockquote><div>=C2=A0</div></div><div><br></div><div>The=
 timeout values I choose are arbitrary, fine-tuned to a number that guarant=
eed, in my tests, to always succeed in allowing the last <i>CAPT</i> line t=
o be displayed. I believe that the numbers would work all the times (hopefu=
lly!).</div><div><br></div><div>Unfortunately I am not hugely experienced w=
ith the Nmap code yet so there could have something there that I am not see=
ing or foreseeing and a review would be nice.</div><div><br></div><div>Does=
 anyone visualise a better approach? Any bad side-effects that I did not se=
e?</div><div><br></div><div>Thanks</div></div></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 17 Mar 2019 at =
22:13, Carlos Carvalho &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br clear=3D"all"><div>Ad=
dresses:</div><div><br></div><div><pre style=3D"color:rgb(0,0,0);white-spac=
e:pre-wrap">* When running Nping echo client with the --no-capture paramete=
r, the last
  packet&#39;s CAPT line is not displayed.</pre></div><div dir=3D"ltr" clas=
s=3D"gmail-m_-7977044168000070825gmail-m_5293023214724693603gmail_signature=
"><div dir=3D"ltr"><div><div dir=3D"ltr"><br></div></div></div></div></div>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail-m_-7977044168000070825gmail_signature"><div dir=3D"ltr"><di=
v><div dir=3D"ltr"><div><font color=3D"#262626"><span style=3D"line-height:=
16px">Carlos Carvalho<br></span></font></div><br></div></div></div></div>

--0000000000009cd3b805858970c0--

--===============2447667465064039790==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
--===============2447667465064039790==--