Hehe.. Commercial software vendors got 'nutin on open source developers. Ask a question and they answer, even if you didn't know they were listening. :)
I have tried various versions, 2.54BETA22 mainly (it always seemed stable). I will give the new one a try shortly. I have to think it has nothing to do with NMAP per se, but rather something else. It seemed to work noticeably better before on the same boxes with the same ISP. There have been a few occasions where the NMAP process just seems to hang, but for the most part, it does complete and will cough up a timer on how long it took. I think I may give the --min_parallelism a shot, though. Are there any other mitigating factors that make a big difference such as: ?? Kernel settings (maybe some kind of DoS defense is messing up when you get a zillion embryonic connections?) Or perhaps the kernel itself or one of the libraries has changed? (maybe the redhat update installed something crippling on top of the default installs over time) I've heard something about libpcap being somewhat broken on RedHat 7.2 ?? To what degree does CPU power count? Not a lick, I'm betting, if you only have a T1 speed connection. Finally I have to think it may have something to do with the ISP somehow. Maybe there's just too much traffic and latency is high. The previous poster suggested something to the effect of checking the return time on a ping, and bumping that up by a factor of 6x - 10x for the rtt setting. Does that sound like a reasonable equation? Are there any documents specifically geared towards tuning that someone could point me to? Thanks everyone for the responses, Mark Lachniet > On Mon, Oct 14, 2002 at 12:14:32PM -0400, [EMAIL PROTECTED] wrote: >> >> I know this isn't really a Nessus issue, but it certainly affects >> Nessus. Over the last 6 months or so, I have seen NMAP performance >> tank heavily on a number of Linux systems I administer. It is a >> particular problem with full NMAP scans such as 'nmap -sT -p 1-65535 >> target.txt'. > > What version of Nmap are you using? I don't think any changes to Nmap > in the last 6 months would have made it slower, but you can always try > an earlier version from http://download.insecure.org/nmap/dist/?M=D . If > an earlier version actually is faster, I'd be interested in hearing > about that. > > One likely culprit is that firewalls on your destination host have > changed. Filters which drop packets on the floor without an ICMP > unreachable are increasingly common, and '-p 1-65535' will take some > time against those hosts. When Nmap returns from a "slow" scan, does it > say something like 'The 65530 ports scanned but not shown below are in > state: filterd'? If so, I am working on speeding up that case. With > Nmap 3.10ALPHA3, you can try the new "--min_parallelism 30" > option, which may help dramatically. Let me know what happens. > > Cheers, > Fyodor > http://www.insecure.org > - > [EMAIL PROTECTED]: general discussions about Nessus. > * To unsubscribe, send a mail to [EMAIL PROTECTED] with > "unsubscribe nessus" in the body. - [EMAIL PROTECTED]: general discussions about Nessus. * To unsubscribe, send a mail to [EMAIL PROTECTED] with "unsubscribe nessus" in the body.
