Re: LAN/WAN Configuration Management

[Ole Morten Grodås <grodaas () gmail com>]

 Hi Fred

Hi Fred

I too might get some difficulties with the current xml output.

I'm currently trying to make the
nmapgui(sourceforge.net/projects/nmapgui<http://sourceforge.net/projects/nmapgui>)
release ready. At the moment I am fixing bugs and minor design issues. For
now there are no problems with the xml output. But when I plan for further
development I can see some problems with the way the GUI communicates with
nmap.

The main problem is the time delay before nmap prints the results to the XML
output. This is making the application less interactive than it could have
been. Users might also get the impression that nmap is a slow scanner. For
example it would have been a great improvement if the result tree was
updated dynamically as nmap got the results. In particular getting the
results from the initial ping scan would have been a great improvment.
Another problem is if you stop a running scan some of the information that
nmap has collected is never printed to the XML output.

> From a GUI or "interactiv" point of view the current xml output method is
kind of a problem. At least when I am scanning a network I want information
as soon as it is available. An advantage of getting the results "live" is
that you can abort the scan as soon as you know "enough". This will reduce
the chances of being detected.

 I agree with Nils Magnus that we should try to avoid adding unnecessary
complexity to nmap. But if we are going to make changes to the way nmap
prints results I think it would be a good Idea to separate the scanner from
the way the results are displayed. Hopefully this can reduce the complexity
of the "scanner".


I propose having a abstract Output class that defines a interfaces that nmap
can use to report results. Then we can have many output classes that uses
this interfaces.

For example:

abstract:
Class Output {
foundNewHost (...);
finishedScanningHost(..);
osDetected(..);
openPorts(..);
closedPorts(..);
....
}

example subclasses of the output class:

DefaultOutput
xmlOutput
grepableOutput
GuiOutput

With this design the scanner does not need to know what happens with the
results. For example the xmlOutput class have to handle the problems of
caching data until it is certain that all the results about a host has
arrived before printing the <host>...</host> info.

By sub classing the output class you could create a graphvizOutput class or
something similar. This would have been perfect for nmapgui at least :)


--
Ole Morten Grodås


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