Nmap Development mailing list archives

Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow.


From: doug () hcsw org
Date: Mon, 11 Aug 2008 13:22:26 -0700

Hi Jay,

On Mon, Aug 11, 2008 at 04:23:05PM +0000 or thereabouts, jayrhine () comcast net wrote:
Okay, it looks like the 4.68 version from sunfreeware still has the issue that I saw originally where it slows down 
in a scan like, "nmap -r -sS -vv -p 0-1024 x.x.x.x".  Apparently it does better in the case where there is absolutely 
no tcp rate limiting, but it has the same issue when there is some tcp rate limiting.  

So it may be the case that the proposed patch is more reliable, but that the original version can be faster "if you 
get lucky" and don't get stuck waiting for select to fire.  

Thanks for trying the patch. Your results are very interesting.
It sounds like the patch would be beneficial for Nmap/Solaris
so I will try to include it in a patch that bundles together
this and the BSD fix as soon as I figure out a reliable way
to apply these ioctl()s on all platforms that will benefit.

What your results tell me is that there is probably a good
reason why buffering is enabled by default on so many kernels.
Pcap is an OLD library and had to be able to process traffic
in real-time on ancient (circa early 90s) hardware/kernels.

In the case of no TCP rate limiting, it makes sense that the
buffer would fill up very quickly as there are many packets
"in flight". In such a situation, buffering probably improves
Nmap's performance thanks to several factors especially reduced
context switching. However, when there is less pipelining, Nmap
can get in a situation where it is waiting for the buffer to
fill up when it could be processing the received packets and
sending new ones.

Linux seems to be just about the only kernel that NEVER buffers
packets. Of course, most kernels aren't as efficient as linux.

Thanks again,

Doug

Attachment: signature.asc
Description: Digital signature


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

Current thread: