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

[jayrhine () comcast net]

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.  

Jay


 -------------- Original message ----------------------
From: jayrhine () comcast net
> 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 net
> > > > The 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 as 
> > fast 
> > > as linux, but it is much faster.  
> > >
> > > For comparison I've scanned an old Solaris 7 host (good for speed tests 
> > because 
> > > it 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 Solaris 
> > one.  
> > > So my conclusion is that your patch results in a really substancial 
> > performance 
> > > improvement, 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


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