Re: Detecting hosts in large subnets

[Hillel <hillel.t () gmail com>]

doug () hcsw org wrote:

> Hi Hillel,
>
>  
>
> > 1. From the sniffer output I see that nmap sends a second arp for every host
> > that does not respond. Is there a way to cancel this behavior?
> >    
>
> Interesting you mention this right now. The next version of Nmap (due out soon)
> should include a new command line option: --max_retries
>
> Read about it here:
>
> I found this:
>
> o Added --max_retries option for capping the maximum number of
>  retransmissions the port scan engine will do. The value may be as low
>  as 0 (no retransmits).  A low value can increase spead, though at the
>  risk of losing accuracy.  The -T4 option now allows up to 6 retries,
>  and -T5 allows 2.  Thanks to Martin Macok
>  (martin.macok(a)underground.cz) for writing the initial patch, which I
>  changed quite a bit.  I also updated the docs to reflect this neat
>  new option.
>
> here:
>
> http://www.insecure.org/nmap/changelog.html
>
> As it says, this is an adaptation of Martin's patch which you can find here:
>
> http://xtrmntr.org/ORBman/tmp/nmap/nmap-3.78-option-max_retransmissions.patch
>
> if you're desperate for the functionality. I believe this patch doesn't allow
> a parameter of 0 (which sends no retransmissions at all) although the official
> version in the next release will.
>
> Although this is exactly the functionality you've asked about, unfortunatley
> I can't recommend a --max_retries of 0 if you are at all concerned with
> accuracy - Use with caution. :)
>
>
>  
Thanks for the info, I will surely check it out when the version comes out.

> > 3. Is there some kind of lib-nmap? The best thing I managed so far was
> > running nmap directly from my app, direct the output to a file and parse it.
> >    
>
> No, there is no separate libnmap although this has been discussed before on
> the mailing lists. See this thread, for instance:
>
> http://seclists.org/lists/nmap-dev/2003/Oct-Dec/0060.html 
>
> A "libnmap" was proposed in the 2003 user survey and didn't exactly get a
> stunning response. (It just barely beat out auto-r00ter):
>
> http://seclists.org/lists/nmap-hackers/2003/Apr-Jun/0011.html
>
> The recommended way to interact with nmap from other programs is
> to use XML output (-oX). Here is the DTD:
>
> http://www.insecure.org/nmap/data/nmap.dtd
>
> From the newest manpage:
>
> XML offers a stable format that is easily parsed by software. Free XML parsers are available for all major computer 
> languages, including C/C++, Perl, Python, and Java. People have even written bindings for most of these languages to 
> handle Nmap output and execution specifically. Examples are Nmap::Scanner  and Nmap::Parser in Perl CPAN. In almost 
> all cases that a non-trivial application interfaces with Nmap, XML is the preferred format.
>  
Yes I have seen the xml output, but hoped for lib. no big problem here 
though.

>  
>
> > 4. Are there any licensing issues when including nmap and libpcap (it's a
> > windows app) in a commercial release?
> >    
>
> libpcap is covered under the BSD license and, as such, can be compiled into
> binaries without making the source available. However, nmap (and associated
> data files such as nmap-service-probes, nmap-os-fingerprints, etc) are covered
> under the GNU GPL. You are required to distribute complete source code if you distribute
> a binary containing code from Nmap. For specifics, see the following files in
> the nmap source tree:
>
> nmap-X.XX/COPYING
> nmap-X.XX/libpcap/LICENSE
>
>
>  
>
> > 5. In I change max_rtt_timeout to 100 the scan time goes from 87 seconds to
> > 150 seconds. Almost a linear increase. This is somewhat counter intuitive to
> > me. I assume the time deficit is because of some limitations on the number
> > of open sockets, that slows down the ability to send arp requests (is it
> > so?).
> >    
>
> Since ARP requests operate way below the socket layer, it's probably
> unlikely this behaviour is caused by userland socket limitations.
>
>  
Any idea's why is it happening? anyone? I set max_scan_delay to 0, so 
theoretically, I would expect the change of max_rtt_timeout from 50 
milli to 100 milli, to add a maximum of 50 milliseconds to the scan time 
(the extra time nmap waits for the last packet it sent). i.e. if the 
packets are being sent at the same rate (due to max_scan_delay), then 
the time nmap waits for response shouldn't be such a significant factor.

> Hope this helps!
>
> Doug Hoyte
>
>  
Helps a lot, Thanks again.

Hillel.



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