On Sat, Jul 05, 2003 at 01:59:40PM +0100, Always Bishan wrote:
> > kind of connection are you doing
> > your tests over ?
> DSL 64 Kbps
Which is slow.
> > What value did you set check_read_timeout to ?
> > (when you do a non-local test, it should at
> > least be 10 seconds).
> WHere do I change or modify this check_read_timeout
> parameter?
Edit you .nessusrc and/or nessusd.conf.
> > How many checks are being performed in parallel ?
> SOrry. I don't know. How do I see this?
that's the max_checks parameters, as well as the max_hosts parameter.
> > How many hosts are being tested in parallel ?
> 4 Hosts in US and I'm in India
Then you are probably overloading your line. What you must understand is
that Nessus can be quite network intensive. From a developper's point of
view, we do everything we can to overcome packets loss - actually, much
better than any other scanner I saw : UDP packets are being transparently
being resent, when plugins do a TCP recv() they attempt to read the
amount of data the server advertises to send and if not, recv() is very
slow (that is, it waits for <checks_read_timeout_time> to return data,
instead of returning as soon as some data is received as most other
scanners do), forged packets are being resent and finally, when writing
a check, bandwidth is always kept in mind.
Now, even with our best efforts, we can not do the impossible. If you
run Nessus in extreme conditions and do not tune it accordingly, then
you will have erratic results - as you did -
but this is how networking works. And if you don't understand anything
about networks and packet losses, maybe you don't want to run Nessus to
start with.
To overcome this problem, you can either set a very very high
checks_read_timeout value (to 120 for instance), you can also reduce the
number of hosts tested at the same time, and finally you can use the QoS
features offered by your operating system to avoid using too much
bandwidth.
-- Renaud
