Nmap Development mailing list archives
Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow.
From: jayrhine () comcast net
Date: Mon, 11 Aug 2008 14:15:27 +0000
hmmm ... some more interesting information on this. It turns out that they just recently put out the 4.68 version of nmap on Sun freeware. There is an announcement on their page from last Thursday. As compared to the version that I compiled myself, this seems substantially faster. Faster even then the version with the patch applied. However, on my first run with the new version, I noticed that Nmap identified the last 35 ports as filtered instead of closed. This is similar to what I was seeing previously where I would do a scan of ports 20-24 and I would sometimes seem the correct services open and sometimes things would appear filtered. Repeating the scan 5 times or so, and I did not see the same result. I'm guessing here that this relates to this select issue. There may be a timing issue where the select does not fire in time, and therefore nmap completes without seeing the responses for the last X ports. I'm also confused out why the 4.68 version from sunfreeware acts so much differently then the one I compiled (or the 4.60/450 versions from sunfreeware). Here you can see the last 35 ports are filtered. 65501/tcp filtered unknown 65502/tcp filtered unknown 65503/tcp filtered unknown 65504/tcp filtered unknown 65505/tcp filtered unknown 65506/tcp filtered unknown 65507/tcp filtered unknown 65508/tcp filtered unknown 65509/tcp filtered unknown 65510/tcp filtered unknown 65511/tcp filtered unknown 65512/tcp filtered unknown 65513/tcp filtered unknown 65514/tcp filtered unknown 65515/tcp filtered unknown 65516/tcp filtered unknown 65517/tcp filtered unknown 65518/tcp filtered unknown 65519/tcp filtered unknown 65520/tcp filtered unknown 65521/tcp filtered unknown 65522/tcp filtered unknown 65523/tcp filtered unknown 65524/tcp filtered unknown 65525/tcp filtered unknown 65526/tcp filtered unknown 65527/tcp filtered unknown 65528/tcp filtered unknown 65529/tcp filtered unknown 65530/tcp filtered unknown 65531/tcp filtered unknown 65532/tcp filtered unknown 65533/tcp filtered unknown 65534/tcp filtered unknown 65535/tcp filtered unknown Jay -------------- Original message ---------------------- From: jayrhine () comcast net
Correction on the speed comparisons, those are for default port ranges instead of a complete scan from 0-65535 ... forget to specify the -p0-65535 option during the scan ... I'll have to rethink the performance improvement. It is still definitely a big improvement, but maybe not as much as I was thinking. looks like a full tcp port scan with no rate limiting, takes about 5 seconds on Linux and 10-12 minutes on Solaris with the patch (it would have taken hours without the patch). Jay -------------- Original message ---------------------- From: jayrhine () comcast netThe most accurate way to tell which nmap is using is to go into its libpcap directory and ./configure :Okay, its definately running DLPI.When you get a chance could you put this code snippet where my OpenBSD patch went in tcpip.cc? It's an *untested* modification of the code from the above message:Okay, I applied this patch and it made a major difference. Its still not asfastas linux, but it is much faster. For comparison I've scanned an old Solaris 7 host (good for speed testsbecauseit has 0 tcp rate limiting, and udp rate limiting can be disabled). Linux Nmap doing a complete TCP Scan (0-65535) - 1.1 seconds Linux Nmap doing a complete UDP Scan (0-65535) - 1.2 seconds Solaris Nmap doing a complete TCP Scan (0-65535) - 20 seconds Solaris Nmap doing a complete UDP Scan (0-65535) - 91 seconds For more comparision, I've also Scanning against a Solaris 10 host (where you cannot completely disable tcp rate limiting) Linux Nmap doing a complete TCP Scan (0-65535) - 45 seconds Linux Nmap doing a complete UDP Scan (0-65535) - 1.6 seconds Solaris Nmap doing a complete TCP Scan (0-65535) - 48 seconds Solaris Nmap doing a complete UDP Scan (0-65535) - 95 seconds I did not notice substancial CPU usage during the scan, so I do not think this is a factor. However, the Linux machine is more powerful than the Solarisone.So my conclusion is that your patch results in a really substancialperformanceimprovement, but clearly there is something that is still slowing it down relative to Linux.Some header files might need to be #included too.. Possibly one or more of these:It turns out I needed to include the following line: #include "sys/bufmod.h" _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 07)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. David Fifield (Aug 07)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. doug (Aug 07)
- <Possible follow-ups>
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 07)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 07)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 08)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 10)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 11)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 11)
- Re: Nmap on Solaris 9 and Solaris 10 not working right? Going way too slow. jayrhine (Aug 11)