Re: Fwd: Sean Rivera Progress report 13/17

[David Fifield <david () bamsoftware com>]

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/