Re: Why does nmap send multiple probes to the same port?

[Casey Williams <Lists () aviditysoftware com>]

I've noticed the same thing with -sS and -P0 which I did't think used connect().  I've 
actually been wondering about this recently myself because I've been writing my own 
lightweight port scanning engine using libnet to inject SYN probes.  I've noticed that if I 
loop over the range of IP addresses and immediately send the probe, I won't always get a 
reply from hosts that I know should have replied.  However, if I sleep() for 1 millisecond 
between probe sends, it *will* send  the reply.  However, this 1 ms sleep() can add up over 
many hosts/ports, and I can't seem to sleep() for a shorter period of time, (even 
nanosleep() doesn't seem to work for me).

***pure conjecture ahead***

So I started wondering how nmap was able to be so reliable and yet SO fast (kudos!).  Then I 
realized that it may be sending these "retry" probes to hosts that it doesn't know the 
status of and that it didn't get a reply from.

I've been reading the nmap source and stepping through it, but I haven't verified that this 
is correct.  Am I on the right track?  If not, would this tactic be unrecommended?

-Casey Williams


On 01:56 Thu 01/12/06 Jan    , Andreas Ericsson wrote:
> chok () chokmah org wrote:
> > I am having trouble with nmap sending multiple probes to 
> > the same port to the same target. Because of this, a scan 
> > of all ports takes many days instead of an hour or two. I 
> > am using nmap version 3.81 on debian 3.1 (sarge).
> >
> > Here is what the scan looks like:
> >
> > # nmap -sT -P0 -p 1-65535 --packet_trace 192.0.2.1
> >
> > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 
> > 2006-01-06 09:47 CST
> > CONN (0.3610s) TCP localhost > 192.0.2.1:21 => Operation 
> > now in progress
>
> It doesn't. EINPROGRESS (the macro for the error-code being returned) is 
> returned, but that doesn't mean nmap is sending the packet. Here's what 
> the connect(2) man-page has to say about it;



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev