mailing list archives
Re: Zenmap Crashing and CPU Utilisation hangs at 50%
From: Rob Nicholls <robert () robnicholls co uk>
Date: Tue, 18 Jan 2011 12:07:20 +0000
On Mon, 17 Jan 2011 12:31:13 -0800, David Fifield wrote:
I don't have a good workaround to suggest other than running the
in a terminal. (You can copy and paste the command line from Zenmap,
a -oX option to save the output, and then open the XML file in Zenmap
later.) Another thing you might try is changing this setting to False
enable_highlight = True
I don't know how much the highlighting contributes to the
but it might be enough to allow your scan to finish.
It makes an incredibly huge difference to a quick test scan I performed
with --packet-trace against a single host (default ports). It managed to
display around 100 lines (rough estimate) before Zenmap stopped
responding (I gave up after a few minutes and killed the process, I
don't know whether waiting for hours would allow it to catch up and get
back to normal). Repeating the scan with enable_highlight set to False
allowed the default scan to complete without any issues. I've just
finished it with --packet-trace against -p- and Zenmap just about coped
okay (the output viewer's scrollbar went mad and the application got
very sluggish towards the end), even though there were a staggering
132178 lines by the end.
The issue is most apparent with a fast/noisy scan (the quick test scan
with -T4 caused Zenmap to play up, but with -T2 it seemed to cope
better, althought it eventually stopped responding about 25% of the way
through the scan). I don't know whether the issue is purely down to the
highlighting taking too long or if the delay causes something more
important to go wrong.
I know the highlighting is pretty, but should we consider disabling it
by default if it's too easy to make Zenmap stop responding?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/