Re: Fwd: Sean Rivera Progress report 13/17

[Luis MartinGarcia <luis.mgarc () gmail com>]

Hi guys,

It's great that you are trying to fix bugs in Nping, but again, please
do not look at the one in svn:\nmap\nping. The current dev version of
Nping is located in nmap-exp/luis/nmap-npingchanges/nping. The Nping
on that branch is very different from the trunk (many new features and
bugfixes there, including the one you are experiencing). I suggest
that you first test whether the bugs you find can be reproduced in the
dev branch, and in that case, to fix them there, not in trunk (unless
the bugs are critical, of course). Otherwise, it's going to be a
nightmare to merge the branch later, as the code has suffered a lot of
changes.

I know I havent been working on the branch for a long long time, but
believe me, that branch is the way to go. So if you could forget about
nmap\nping and take the npingchanges one a a reference, it would be
great.

Thank you, and best regards,

Luis MartinGarcia.




        It's great that you are fixing some bugs in Nping! Just note
     that
On Tue, Jul 24, 2012 at 10:42 AM, David Fifield <david () bamsoftware com> wrote:
> On Tue, Jul 24, 2012 at 11:19:06AM -0600, sean rivera wrote:
> > The problem is somewhere in lines 398-410 (Or 448-460 for icmp and arp
> > packets).
> > > From my testing I've noticed that the error does not show up with the -N
> > flag (So it needs the scheduled packet read) and it only works on a single
> > packet sent (-c1).
> > I've also found that setting the delay can change the error message or
> > eliminate it all together.
> > By running a simple shell script that caught stderr and tossed into a file
> > --delay flag value I've found some interesting results for single packet
> > sends.
> > Results:
> > Delay = 2
> > Always prints two
> > nping_event_handler(): READ-PCAP killed: Resource temporarily unavailable
> > nping_event_handler(): READ-PCAP killed: Resource temporarily unavailable
> > Which I believe comes from
> >  nsock_pcap_read_packet(nsp, pcap_nsi, nping_event_handler, o.getDelay(),
> > NULL);
> >
> > Delay =1
> > Race condition exists here which makes sense, as delay=1 is the default
> > value
> >
> > Delay <1 and delay is greater then .1
> > Same deal with the race conditions.
> >
> > Delay <=.1
> > I've tried running this hundreds of times and I cannot get the
> > nping_event_handler(): TIMER killed: Resource temporarily unavailable.
>
> These are good tests to run. It looks like you're making progress.
>
> delay has type int, so I'm confused by what you're saying about delay <= 1.
> Does that mean you have tried, for example, delay = 0.5? Isn't the
> compiler rounding that to an int? It seems the only reasonable values to
> test are 1 and 0.
>
> It will probably help your debugging to track nsock_event_ids. These are
> just long ints. An nsock_event_id is returned, for example, from
> nsock_timer_create. Print out that id, and then add some debugging code
> to print the id in nping_event_handler. Then you can surely match up
> event creation and deletion.
>
> You can also get tons of Nsock debugging output by increasing the value
> given to nsp_settrace in nping/ProbeMode.cc.
>
> > > From my testing so far I think the race condition is a combo of the
> >
> > "nsock_pcap_read_packet(nsp, pcap_nsi, nping_event_handler, o.getDelay(),
> > NULL);"
> >
> > scheduled event and the
> >
> > "nsock_timer_create(nsp, nping_event_handler, 1, &pkts2send[pc]);"
> >
> > that is called only on the first time.
> >
> > I am also pretty sure that it is because of that hard coded 1 for time out.
> > (Every other time it is o.getDelay() but I'll need to test that.
>
> The constant timeout of 1 ms might have something to do with it. It
> seems that instead of directly sending the first probe, we schedule a
> timer with a negligible timeout, which does the actual send when it
> expires? I guess that is for uniformity with how the subsequent probes
> are sent. But maybe we should just send the first probe? Or use a
> timeout of 0? (But check if a timeout of 0 has a special meaning first.)
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/